One document matched: draft-ietf-mmusic-rfc2326bis-18.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-ietf-mmusic-rfc2326bis-18.txt"
ipr="full3978">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<front>
<title abbrev="Real Time Streaming Protocol 2.0 (RTSP)">Real Time
Streaming Protocol 2.0 (RTSP)</title>
<author fullname="Henning Schulzrinne" initials="H.S."
surname="Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>1214 Amsterdam Avenue</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>USA</country>
</postal>
<email>schulzrinne@cs.columbia.edu</email>
</address>
</author>
<author fullname="Anup Rao" initials="A.R." surname="Rao">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>anrao@cisco.com</email>
</address>
</author>
<author fullname="Rob Lanphier" initials="R.L." surname="Lanphier">
<organization></organization>
<address>
<postal>
<street></street>
<city>Seattle</city>
<region>WA</region>
<code></code>
<country>USA</country>
</postal>
<email>robla@robla.net</email>
</address>
</author>
<author fullname="Magnus Westerlund" initials="M.W." surname="Westerlund">
<organization>Ericsson AB</organization>
<address>
<postal>
<street>Färögatan 6</street>
<city>STOCKHOLM</city>
<region></region>
<code>SE-164 80</code>
<country>SWEDEN</country>
</postal>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Martin Stiemerling" initials="M."
surname="Stiemerling (Ed.)">
<organization abbrev="NEC">NEC Laboratories Europe, NEC Europe
Ltd.</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<phone>+49 (0) 6221 4342 113</phone>
<email>stiemerling@nw.neclab.eu</email>
</address>
</author>
<date year="2008" />
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>MMUSIC Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>INTERNET-DRAFT</keyword>
<keyword>mmusic, RTSP, RTSP/2.0, real-time streaming protocol</keyword>
<abstract>
<t>This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in RFC 2326.</t>
<t>The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable controlled,
on-demand delivery of real-time data, such as audio and video. Sources
of data can include both live data feeds and stored clips. This protocol
is intended to control multiple data delivery sessions, provide a means
for choosing delivery channels such as UDP, multicast UDP and TCP, and
provide a means for choosing delivery mechanisms based upon RTP (RFC
3550).</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<section anchor="sec_basic-intro" title="Scope and Background">
<t>This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0) which is an application-level protocol for control over the
delivery of data with real-time properties, typically streaming media.
Streaming media is, for instance, video on demand or audio live
streaming. Put simply, RTSP acts as a "network remote control" for
multimedia servers, as you know it from your TV set.</t>
<t>The protocol operates between RTSP 2.0 clients and servers, but
also supports the usage of RTSP 2.0 proxies between clients and
servers. Basically, clients can request information about streaming
media from servers, by asking for a description of the media or use
media description provided externally. Based on the media description
clients can request to play out the media, pause it, or stop it
completely, as known from a regular TV remote control. The requested
media can consist of multiple audio and video streams that are
delivered as a time-synchronized streams from servers to clients.</t>
<t>This memorandum describes the use of RTSP over a reliable
connection based transport level protocol, such as TCP. For security,
TLS over a connection oriented transport is supported.</t>
<t>There is no dependency on an special RTSP connection in the
protocol. Instead, an RTSP server maintains a session labeled by an
identifier to associate groups of media streams and their states. An
RTSP session is not tied to a transport-level connection such as a TCP
connection. During a session, a client may open and close multiple
reliable transport connections to the server to issue RTSP requests
for that session.</t>
<t>The set of streams to be controlled in an RTSP session is defined
by a presentation description. This memorandum does not define a
format for the presentation description. However <xref
target="sec_sdpusage"></xref> describes how SDP <xref
target="RFC4566"></xref> is used for this purpose. The streams
controlled by RTSP may use RTP <xref target="RFC3550"></xref> for
their data transport, but the operation of RTSP does not depend on the
transport mechanism used to carry continuous media. RTSP is
intentionally similar in syntax and operation to HTTP/1.1 <xref
target="RFC2616"></xref> so that extension mechanisms to HTTP may also
be applied to RTSP.</t>
<t>The RTSP 2.0 protocol supports the following operations: <list
hangIndent="6" style="hanging">
<t hangText="Retrieval of media from media server:">The client can
either request a presentation description via RTSP DESCRIBE, HTTP
or some other method. If the presentation is being multicast, the
presentation description contains the multicast addresses and
ports to be used for the continuous media. If the presentation is
to be sent only to the client via unicast, the client provides the
destination.</t>
<t hangText="Invitation of a media server to a conference:">A
media server can be "invited" to join an existing conference to
play back media into the presentation. This mode is useful, for
example, in distributed teaching applications. Several parties in
the conference may take turns "pushing the remote control
buttons". Note: This functionality will require RTSP external
application level functionality.</t>
</list></t>
<t>RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1 <xref target="RFC2616"></xref>.</t>
</section>
<section anchor="RTSPSpecUpdate" title="RTSP Specificication Update">
<t>This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0,
a proposed standard defined in <xref target="RFC2326"></xref>. The
goal of this version is to correct the many flaws that have been
identified in RTSP 1.0 since its publication. The corrections are such
that backwards compatibility was impossible. Thus a new version was
deemed the most appropriate solution to get a more functional
protocol. There are no plans to revise RTSP 1.0. <xref
target="sec_changes"></xref> catalogs the changes of this version in
relation to RTSP 1.0.</t>
<t>RTSP 2.0 as specified in this memo has reduced functionality
compared to RTSP 1.0 and aims at specifying the RTSP core,
functionality and rules for extensions, and basic interaction with the
media delivery protocol <xref target="RFC3550">RTP</xref>.</t>
<t>Any other functionality would need to be published as extension
documents. This specification provides rules for such extensions and
defines registries to avoid naming collisions.</t>
</section>
<section anchor="NotationalConventions" title="Notational Conventions">
<t>Since some of the definitions and syntax are identical to HTTP/1.1,
this specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer to
Section X.Y of the current HTTP/1.1 specification (<xref
target="RFC2616"></xref>).</t>
<t>All the mechanisms specified in this document are described in both
prose and the Augmented Backus-Naur form (ABNF) described in detail in
<xref target="RFC5234"></xref>.</t>
<t>Indented and smaller-type paragraphs are used to provide
informative background and motivation. This is intended to give
readers who were not involved with the formulation of the
specification an understanding of why things are the way they are in
RTSP.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t>The word, "unspecified" is used to indicate functionality or
features that are not defined in this specification. Such
functionality cannot be used in a standardized manner without further
definition in an extension specification to RTSP.</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>Some of the terminology has been adopted from HTTP/1.1 <xref
target="RFC2616"></xref>. Terms not listed here are defined as in
HTTP/1.1. <list style="hanging">
<t hangText="Aggregate control:">The concept of controlling
multiple streams using a single timeline, generally maintained by
the server. A client, for example, uses aggregate control when it
issues a single play or pause message to simultaneously control
both the audio and video in a movie. A session which is under
aggregate control is referred to as an aggregated session.</t>
<t hangText="Aggregate control URI:">The URI used in an RTSP
request to refer to and control an aggregated session. It
normally, but not always, corresponds to the presentation URI
specified in the session description. See <xref
target="sec_SETUP"></xref> for more information.</t>
<t hangText="Conference:">A multiparty, multimedia presentation,
where "multi" implies greater than or equal to one.</t>
<t hangText="Client:">The client requests media service from the
media server.</t>
<t hangText="Connection:">A transport layer virtual circuit
established between two programs for the purpose of
communication.</t>
<t hangText="Container file:">A file which may contain multiple
media streams which often constitutes a presentation when played
together. The concept of a container file is not embedded in the
protocol. However, RTSP servers may offer aggregate control on the
media streams within these files.</t>
<t hangText="Continuous media:">Data where there is a timing
relationship between source and sink; that is, the sink needs to
reproduce the timing relationship that existed at the source. The
most common examples of continuous media are audio and motion
video. Continuous media can be real-time (interactive or
conversational), where there is a "tight" timing relationship
between source and sink, or streaming (playback), where the
relationship is less strict.</t>
<t hangText="Entity:">The information transferred as the payload
of a request or response. An entity consists of meta-information
in the form of entity-header fields and content in the form of an
entity-body, as described in <xref
target="sec_entity"></xref>.</t>
<t hangText="Feature-tag:">A tag representing a certain set of
functionality, i.e. a feature.</t>
<t hangText="IRI:">Internationalized Resource Identifier, is the
same as an URI, with the exception that it allows characters from
the whole Universal Character Set (Unicode/ISO 10646), rather than
the US-ASCII only. See <xref target="RFC3987"></xref> for more
information.</t>
<t hangText="Live:">Normally used to describe a presentation or
session with media coming from an ongoing event. This generally
results in the session having an unbound or only loosely defined
duration, and sometimes no seek operations are possible.</t>
<t hangText="Media initialization:">Datatype/codec specific
initialization. This includes such things as clock rates, color
tables, etc. Any transport-independent information which is
required by a client for playback of a media stream occurs in the
media initialization phase of stream setup.</t>
<t hangText="Media parameter:">Parameter specific to a media type
that may be changed before or during stream playback.</t>
<t hangText="Media server:">The server providing playback services
for one or more media streams. Different media streams within a
presentation may originate from different media servers. A media
server may reside on the same host or on a different host from
which the presentation is invoked.</t>
<t hangText="Media server indirection:">Redirection of a media
client to a different media server.</t>
<t hangText="(Media) stream:">A single media instance, e.g., an
audio stream or a video stream as well as a single whiteboard or
shared application group. When using RTP, a stream consists of all
RTP and RTCP packets created by a source within an RTP
session.</t>
<t hangText="Message:">The basic unit of RTSP communication,
consisting of a structured sequence of octets matching the syntax
defined in <xref target="sec_syntax"></xref> and transmitted over
a connection or a connectionless transport.</t>
<t hangText="Non-Aggregated Control:">Control of a single media
stream. This is only possible in RTSP sessions with a single
media.</t>
<t hangText="Participant:">Member of a conference. A participant
may be a machine, e.g., a playback server.</t>
<t hangText="Presentation:">A set of one or more streams presented
to the client as a complete media feed and described by a
presentation description as defined below. Presentations with more
than one media stream are often handled in RTSP under aggregate
control.</t>
<t hangText="Presentation description:">A presentation description
contains information about one or more media streams within a
presentation, such as the set of encodings, network addresses and
information about the content. Other IETF protocols such as SDP
(<xref target="RFC4566"></xref>) use the term "session" for a
presentation. The presentation description may take several
different formats, including but not limited to the session
description protocol format, SDP.</t>
<t hangText="Response:">An RTSP response. If an HTTP response is
meant, that is indicated explicitly.</t>
<t hangText="Request:">An RTSP request. If an HTTP request is
meant, that is indicated explicitly.</t>
<t hangText="Request-URI:">The URI used in a request to indicate
the resource on which the request is to be performed.</t>
<t hangText="RTSP agent:">Refers to either an RTSP client, an RTSP
server, or an RTSP Proxy. In this specification, there are many
capabilities that are common to these three entities such as the
capability to send requests or receive responses. This term will
be used when describing functionality that is applicable to all
three of these entities.</t>
<t hangText="RTSP session:">A stateful abstraction upon which the
main control methods of RTSP operate. An RTSP session is a server
entity; it is created, maintained and destroyed by the server. It
is established by an RTSP server upon the completion of a
successful SETUP request (when a 200 OK response is sent) and is
labelled with a session identifier at that time. The session
exists until timed out by the server or explicitly removed by a
TEARDOWN request. An RTSP session is a stateful entity; an RTSP
server maintains an explicit session state machine (see Appendix
A) where most state transitions are triggered by client requests.
The existence of a session implies the existence of state about
the session's media streams and their respective transport
mechanisms. A given session can have one or more media streams
associated with it. An RTSP server uses the session to aggregate
control over multiple media streams.</t>
<t hangText="Transport initialization:">The negotiation of
transport information (e.g., port numbers, transport protocols)
between the client and the server.</t>
<t hangText="URI:">Universal Resource Identifier, see <xref
target="RFC3986"></xref>. The URIs used in RTSP are generally URLs
as they give a location for the resource. As URLs are a subset of
URIs, they will be referred to as URIs to cover also the cases
when an RTSP URI would not be an URL.</t>
<t hangText="URL:">Universal Resource Locator, is an URI which
identifies the resource through its primary access mechanism,
rather than identifying the resource by name or by some other
attribute(s) of that resource.</t>
<t></t>
</list></t>
</section>
<section anchor="sec_Media-Properties-Intro" title="Media Properties">
<t>When RTSP handles media it is important to consider the different
properties a media instance for playback can have. This specification
considers the below listed media properties in its protocol
operations. They are derived from the differencies between a number of
supported usages. <list style="hanging">
<t hangText="On-demand:">Media that has a fixed (given) duration
that doesn't change during the life time of the RTSP session and
are known at the time of the creation of the session. It is
expected that the content of the media will not change, even if
the representation, i.e encoding, quality, etc, may change.
Generally one can seek within the media i.e. randomly access any
range of the media stream to playback.</t>
<t hangText="Dynamic On-demand:">This is a variation of the
on-demand case where external methods are used to manipulate the
actual content of the media setup for the RTSP session. The main
example is where a playlist determines the content of the
session.</t>
<t hangText="Live:">Live media represents a progressing content
stream (such as broadcast TV) where the duration may or may not be
known. It is not seakable, only the content presently being
delivered can be accessed.</t>
<t hangText="Live with Recording:">A Live stream that is combined
with a server side capability to store and retain the content of
the live session for random access playback within the part of the
already recorded content. The actual behavior of the media stream
is very much depending on the retention policy for the media
stream. Either the server will be able to capture the complete
media stream, or it will have a limitation in how much will be
retained. The media range will dynamically change as the session
progress. For servers with a limited amount of storage available
for recording, there will be a sliding window that goes forwards
while data is made available and content that is older than the
limitation will be discarded.</t>
</list></t>
<t>Considering the above usages one get the following media properties
and their different instance values.</t>
<section title="Random Access">
<t>Random Access, i.e. if one can request that the playback point is
moved from one point in the media duration to another. The following
different values are considered:</t>
<t><list style="hanging">
<t hangText="Random Access:">Yes the media are seekable to any
out of a large number of points within the media. Due to media
encoding limitations a particular point may not be reachable,
but seeking to a point close by is enabled. A floating point
number of seconds may be provied to express the worst case
distance between random access points.</t>
<t hangText="Return To Start:">Seeking is only possible to
begining of the content.</t>
<t hangText="No seeking:">Seeking is not possible at all.</t>
</list></t>
</section>
<section title="Retention">
<t>Media may have different retention policy in place that affect
the operation on the media. The following different media retention
policies are envisioned and taken into consideration where
applicable.</t>
<t><list style="hanging">
<t hangText="Unlimited:">The media will not be removed as long
as the RTSP session are in existence.</t>
<t hangText="Time Limited:">The media will at least not be
removed before given wall clock time. After that time it may or
may not be available any more.</t>
<t hangText="Duration limited">Each indiviudal unit of the media
will be retained for the specified duration.</t>
</list></t>
<t></t>
</section>
<section title="Content Modifications">
<t>There is also the question of how the content may change during
time for a give media resource:</t>
<t><list style="hanging">
<t hangText="Unmutable:">The content of the media will not
change, even if the representation, i.e encoding, quality, etc,
may change.</t>
<t hangText="Dynamic:">Between explicit updates the media
content will not change, but the content may change due to
external methods or triggers, such as playlists.</t>
<t hangText="Time Progressing:">As times progress new content
will become available. If the content also is retained it will
become longer and longer as everything between the start point
and the point in currently being made available can be
accessed.</t>
</list></t>
<t></t>
</section>
<section title="Mapping to the Attributes">
<t>This section exemplifies how one would map the above listed
usages to the properties and their values.</t>
<t><list style="hanging">
<t hangText="On-demand:">Random Access: Random Access=5s,
Content Modifications: Unmutable, Retention: unlimted or time
limited.</t>
<t hangText="Dynamic On-demand:">Random Access: Random
Access=3s, Content Modifications: Dynamic, Retention: unlimted
or time limited.</t>
<t hangText="Live:">Random Access: No seeking, Content
Modifications: Time Progressing, Retention: Duration
limited=0.0s</t>
<t hangText="Live with Recording:">Random Access: Random
Access=3s, Content Modifications: Time Progressing, Retention:
Duration limited=2H</t>
</list></t>
</section>
</section>
</section>
<section anchor="sec_rtsp-intro" title="RTSP Introduction">
<section anchor="ProtocolProperties" title="Protocol Properties">
<t>RTSP has the following properties: <list style="hanging">
<t hangText="Extendable:">New methods and parameters can be easily
added to RTSP.</t>
<t hangText="Secure:">RTSP re-uses web security mechanisms, either
at the transport level (TLS, <xref target="RFC4346"></xref>) or
within the protocol itself. All HTTP authentication mechanisms
such as basic (<xref target="RFC2616"></xref>) and digest
authentication (<xref target="RFC2617"></xref>) are directly
applicable.</t>
<t hangText="Transport-independent:">RTSP does not preclude the
use of unreliable datagram protocol (UDP) (<xref
target="RFC0768"></xref>) as it would be possible to implement
application-level reliability. The use of a connectionless
datagram protocol such as UDP requires additional definition that
may be provided as extensions to the core RTSP specification. The
reliable stream protocol TCP (<xref target="RFC0793"></xref>) and
the secured reliable stream protocol TLS over TCP <xref
target="RFC4346"></xref> are the currently defined transport
protocols for RTSP messages.</t>
<t hangText="Media-delivery protocol independent:">The operation
of RTSP does not depend on the transport mechanism used to carry
continuous media. While most real-time media will use RTP as a
transport protocol, RTSP does not preclude the use of other
protocols such as MPEG-2 <xref target="ISO.13818-1.2000"></xref>.
The use of other protocols requires additional definition that may
be provided as extensions to the core RTSP specification.</t>
<t hangText="Multi-server capable:">Each media stream within a
presentation can reside on a different server. The client
automatically establishes several concurrent control sessions with
the different media servers. Media synchronization in those cases
is performed at the transport level.</t>
<t
hangText="Separation of stream control and conference initiation:">Stream
control is divorced from inviting a media server to a conference.
In particular, SIP <xref target="RFC3261"></xref> or H.323 <xref
target="ITU.H323.1996"></xref> may be used to invite a server to a
conference; however, the exact procedures are unspecified.</t>
<t hangText="Suitable for professional applications:">RTSP
supports frame- level accuracy through SMPTE time stamps to allow
remote digital editing.</t>
<t hangText="Presentation description neutral:">The protocol does
not impose a particular presentation description or metafile
format and can convey the type of format to be used. However, the
presentation description is required to contain at least one RTSP
URI.</t>
<t hangText="Proxy and firewall friendly:">The protocol should be
readily handled by both application and transport-layer (SOCKS
<xref target="RFC1961"></xref>) firewalls. A firewall may need to
understand the SETUP method to open a "hole" for the media
stream.</t>
<t hangText="HTTP-friendly:">Where sensible, RTSP reuses HTTP
concepts, so that the existing infrastructure can be reused. This
infrastructure includes PICS (Platform for Internet Content
Selection <xref target="W3C.REC-PICS-services"></xref> <xref
target="W3C.REC-PICS-labels"></xref>) for associating labels with
content. However, RTSP does not just add methods to HTTP since
controlling continuous media requires server state in most
cases.</t>
<t hangText="Appropriate server control:">If a client can start a
stream, it needs to be able to stop a stream. Servers should not
start streaming to clients in such a way that clients cannot stop
the stream.</t>
<t hangText="Transport negotiation:">The client can negotiate the
transport method prior to actually needing to process a continuous
media stream.</t>
</list></t>
</section>
<section anchor="sec_http-rtsp" title="RTSP's Relationship to HTTP">
<t>RTSP is intentionally similar in syntax and operation to HTTP/1.1
<xref target="RFC2616"></xref> so that extension mechanisms to HTTP
can in some cases also be applied to RTSP. However, RTSP differs in a
number of important aspects from HTTP: <list hangIndent="3"
style="empty">
<t><list hangIndent="3" style="symbols">
<t>RTSP introduces a number of new methods and has a different
protocol identifier.</t>
<t>RTSP has the notion of a session built into the
protocol.</t>
<t>An RTSP server needs to maintain state in almost all cases,
as opposed to the stateless nature of HTTP.</t>
<t>Both an RTSP server and client can issue requests.</t>
<t>Data is usually carried out-of-band by a different
protocol. Session descriptions returned in a DESCRIBE response
(see <xref target="sec_DESCRIBE"></xref>) and interleaving of
RTP with RTSP over TCP are exceptions to this rule (see <xref
target="sec_binary"></xref>).</t>
<t>RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts
<xref target="RFC2070"></xref>.</t>
<t>The Request-URI always contains the absolute URI. Because
of backward compatibility with a historical blunder, HTTP/1.1
<xref target="RFC2616"></xref> carries only the absolute path
in the request and puts the host name in a separate header
field. <vspace blankLines="0" /> This makes "virtual hosting"
easier, where a single host with one IP address hosts several
document trees.</t>
</list></t>
</list></t>
</section>
<section anchor="sec_extend-rtsp" title="Extending RTSP">
<t>Since not all media servers have the same functionality, media
servers by necessity will support different sets of requests. For
example: <list style="symbols">
<t>A server may not be capable of seeking (absolute positioning)
if it is to support live events only.</t>
<t>Some servers may not support setting stream parameters and thus
not support GET_PARAMETER and SET_PARAMETER.</t>
<t>Some server may support an RTSP extension.</t>
</list></t>
<t>It is up to the creators of presentation descriptions not to ask
the impossible of a server. This situation is similar in HTTP/1.1
<xref target="RFC2616"></xref>, where the methods described in [H19.5]
are not likely to be supported across all servers.</t>
<t>RTSP can be extended in three ways, listed here in order of the
magnitude of changes supported: <list style="symbols">
<t>Existing methods can be extended with new parameters, e.g.
headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgement when a
method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or
Proxy-Require headers (see <xref
target="sec_Proxy-Require"></xref>).</t>
<t>New methods can be added. If the recipient of the message does
not understand the request, it MUST respond with error code 501
(Not Implemented) so that the sender can avoid using this method
again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server MUST list the methods
it supports using the Public response header.</t>
<t>A new version of the protocol can be defined, allowing almost
all aspects (except the position of the protocol version number)
to change. A new version of the protocol MUST be registered
through an IETF standard track document.</t>
</list></t>
<t>The basic capability discovery mechanism can be used to both
discover support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of this
see <xref target="sec_capability"></xref>.</t>
</section>
<section anchor="OverallOperation" title="Overall Operation">
<t>Each presentation and media stream is identified by an RTSP URI.
The overall presentation and the properties of the media the
presentation is composed of are defined by a presentation description
file, the format of which is outside the scope of this specification.
The presentation description file may be obtained by the client using
HTTP or other means such as email and may not necessarily be stored on
the media server.</t>
<t>For the purposes of this specification, a presentation description
is assumed to describe one or more presentations, each of which
maintains a common time axis. For simplicity of exposition and without
loss of generality, it is assumed that the presentation description
contains exactly one such presentation. A presentation may contain
several media streams.</t>
<t>The presentation description file contains a description of the
media streams making up the presentation, including their encodings,
language, and other parameters that enable the client to choose the
most appropriate combination of media. In this presentation
description, each media stream that is individually controllable by
RTSP is identified by an RTSP URI, which points to the media server
handling that particular media stream and names the stream stored on
that server. Several media streams can be located on different
servers; for example, audio and video streams can be split across
servers for load sharing. The description also enumerates which
transport methods the server is capable of.</t>
<t>Besides the media parameters, the network destination address and
port need to be determined. Several modes of operation can be
distinguished: <list style="hanging">
<t hangText="Unicast:">The media is transmitted to the source of
the RTSP request or the requested destination, with the port
number chosen by the client. Alternatively, the media is
transmitted on the same reliable stream as RTSP.</t>
<t hangText="Multicast, server chooses address:">The media server
picks the multicast address and port. This is the typical case for
a live or near-media-on-demand transmission.</t>
<t hangText="Multicast, client chooses address:">If the server is
to participate in an existing multicast conference, the multicast
address, port and encryption key are given by the conference
description, established by means outside the scope of this
specification, for example by a SIP created conference.</t>
</list></t>
</section>
<section anchor="RTSPStates" title="RTSP States">
<t>RTSP controls a stream which may be sent via a separate protocol,
independent of the control channel. For example, RTSP control may be
transported on a TCP connection while the media data is conveyed via
UDP. Thus, data delivery continues even if no RTSP requests are
received by the media server. Also, during its lifetime a single media
stream may be controlled by RTSP requests issued sequentially on
different TCP connections. Therefore, the server needs to maintain
"session state" to be able to correlate RTSP requests with a stream.
The state transitions are described in Appendix A.</t>
<t>Many methods in RTSP do not contribute to state. However, the
following play a central role in defining the allocation and usage of
stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and
TEARDOWN. <list style="hanging">
<t hangText="SETUP:">Causes the server to allocate resources for a
stream and create an RTSP session.</t>
<t hangText="PLAY:">Starts data transmission on a stream allocated
via SETUP.</t>
<t hangText="PAUSE:">Temporarily halts a stream without freeing
server resources.</t>
<t hangText="REDIRECT:">Indicates that the session should be moved
to a new server or location</t>
<t hangText="TEARDOWN:">Frees resources associated with the
stream. The RTSP session ceases to exist on the server.</t>
</list></t>
<t>RTSP methods that contribute to state use the Session header field
(<xref target="sec_Supported"></xref>) to identify the RTSP session
whose state is being manipulated. The server generates session
identifiers in response to SETUP requests (<xref
target="sec_SETUP"></xref>).</t>
</section>
<section anchor="RelationshipwithOtherProtocols"
title="Relationship with Other Protocols">
<t>RTSP has some overlap in functionality with HTTP. It also may
interact with HTTP in that the initial contact with streaming content
will often be made through a web page. The current protocol
specification aims to allow different hand-off points between a web
server and the media server implementing RTSP. For example, the
presentation description can be retrieved using HTTP or RTSP, which
reduces round trips in web-browser-based scenarios, yet also allows
for stand alone RTSP servers and clients which do not rely on HTTP at
all. However, RTSP differs fundamentally from HTTP in that most data
delivery takes place out-of-band in a different protocol. HTTP is an
asymmetric protocol where the client issues requests and the server
responds. In RTSP, both the media client and media server can issue
requests. RTSP requests are also stateful; they may set parameters and
continue to control a media stream long after the request has been
acknowledged.</t>
<t>Re-using HTTP functionality has advantages in at least two areas,
namely security and proxies. The requirements are very similar, so
having the ability to adopt HTTP work on caches, proxies and
authentication is valuable.</t>
<t>RTSP assumes the existence of a presentation description format
that can express both static and temporal properties of a presentation
containing several media streams. Session Description Protocol (SDP)
<xref target="RFC4566"></xref> is generally the format of choice;
however, RTSP is not bound to it. For data delivery, most real-time
media will use RTP as a transport protocol. While RTSP works well with
RTP, it is not tied to RTP.</t>
</section>
</section>
<section anchor="sec_usecases" title="RTSP Use Cases">
<t>This section describes the most important and considered use cases
for RTSP. They are listed in descending order of importance in regards
to ensuring that all necessary functionality is present. This
specification only fully supports usage of the two first. Also in these
first two cases, there are special cases or exceptions that are not
supported without extensions, e.g. the redirection of media to another
address than the controlling entity.</t>
<section anchor="sec_usecases-on-demand"
title="On-demand Playback of Stored Content">
<t>An RTSP capable server stores content suitable for being streamed
to a client. A client desiring playback of any of the stored content
uses RTSP to set up the media transport required to deliver the
desired content. RTSP is then used to initiate, halt and manipulate
the actual transmission (playout) of the content. RTSP is also
required to provide necessary description and synchronization
information for the content.</t>
<t>The above high level description can be broken down into a number
of functions that RTSP needs to be capable of. <list hangIndent="6"
style="hanging">
<t hangText="Presentation Description:">Provide initialization
information about the presentation (content); for example, which
media codecs are needed for the content. Other information that is
important includes the number of media stream the presentation
contains, the transport protocols used for the media streams, and
identifiers for these media streams. This information is required
before setup of the content is possible and to determine if the
client is even capable of using the content. <vspace
blankLines="1" /> This information need not be sent using RTSP;
other external protocols can be used to transmit the transport
presentation descriptions. Two good examples are the use of HTTP
<xref target="RFC2616"></xref> or email to fetch or receive
presentation descriptions like SDP <xref
target="RFC4566"></xref></t>
<t hangText="Setup:">Set up some or all of the media streams in a
presentation. The setup itself consist of selecting the protocol
for media transport and the necessary parameters for the protocol,
like addresses and ports.</t>
<t hangText="Control of Transmission:">After the necessary media
streams have been established the client can request the server to
start transmitting the content. The client must be allowed to
start or stop the transmission of the content at arbitrary times.
The client must also be able to start the transmission at any
point in the timeline of the presentation.</t>
<t hangText="Synchronization:">For media transport protocols like
RTP <xref target="RFC3550"></xref> it might be beneficial to carry
synchronization information within RTSP. This may be due to either
the lack of inter-media synchronization within the protocol
itself, or the potential delay before the synchronization is
established (which is the case for RTP when using RTCP).</t>
<t hangText="Termination:">Terminate the established contexts.</t>
</list> For this use case there are a number of assumptions about
how it works. These are: <list hangIndent="6" style="hanging">
<t hangText="On-Demand content:">The content is stored at the
server and can be accessed at any time during a time period when
it is intended to be available.</t>
<t hangText="Independent sessions:">A server is capable of serving
a number of clients simultaneously, including from the same piece
of content at different points in that presentations
time-line.</t>
<t hangText="Unicast Transport:">Content for each individual
client is transmitted to them using unicast traffic.</t>
</list> It is also possible to redirect the media traffic to a
different destination than that of the entity controlling the traffic.
However, allowing this without appropriate mechanisms for checking
that the destination approves of this allows for distributed denial of
service attacks (DDoS).</t>
</section>
<section title="Unicast distribution of Live Content">
<t>This use cases is similar to the above on-demand content case (see
<xref target="sec_usecases-on-demand"></xref>) the difference is the
nature of the content itself. Live content is continuously distributed
as it becomes available from 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 server.</t>
<t>In many cases the consumer of live content is only interested in
consuming what is actually happens "now"; i.e., very similar to
broadcast TV. However in this case it is assumed that there exist no
broadcast or multicast channel to the users, and instead the server
functions as a distribution node, sending the same content to multiple
receivers, using unicast traffic between server and client. This
unicast traffic and the transport parameters are individually
negotiated for each receiving client.</t>
<t>Another aspect of live content is that it often has a very limited
time of availability, as it is only is available for the duration of
the 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
time. Thus there is need to announce when and for how long the live
content is available.</t>
<t>In some cases, the server providing live content may be saving some
or all of the content to allow clients to pause the stream and resume
it from the paused point, or to "rewind" and play continuously from a
point earlier than the live point. Hence, this use case does not
necessarily exclude playing from other than the live point of the
stream, playing with scales other than 1.0, etc.</t>
</section>
<section title="On-demand Playback using Multicast">
<t>It is possible to use RTSP to request that media be delivered to a
multicast group. The entity setting up the session (the controller)
will then control when and what media is delivered to the group. This
use case has some potential for denial of service attacks by flooding
a multicast group. Therefore, a mechanism is needed to indicate that
the group actually accepts the traffic from the RTSP server.</t>
<t>An open issue in this use case is how one ensures that all
receivers listening to the multicast or broadcast receives the session
presentation configuring the receivers. This memo has to rely on a
external solution to solve this issue.</t>
</section>
<section title="Inviting an RTSP server into a conference">
<t>If one has an established conference or group session, it is
possible to have an RTSP server distribute media to the whole group.
Transmission to the group is simplest when controlled by a single
participant or leader of the conference. Shared control might be
possible, but would require further investigation and possibly
extensions.</t>
<t>This use case assumes that there exists either multicast or a
conference focus that redistribute media to all participants.</t>
<t>This use case is intended to be able to handle the following
scenario: A conference leader or participant (hereafter called the
controller) has some pre-stored content on an RTSP server that he
wants to share with the group. The controller sets up an RTSP session
at the streaming server for this content and retrieves the session
description for the content. The destination for the media content is
set to the shared multicast group or conference focus. When desired by
the controller, he/she can start and stop the transmission of the
media to the conference group.</t>
<t>There are several issues with this use case that are not solved by
this core specification for RTSP: <list hangIndent="6" style="hanging">
<t hangText="Denial of service:">To avoid an RTSP server from
being an unknowing participant in a denial of service attack the
server needs to be able to verify the destination's acceptance of
the media. Such a mechanism to verify the approval of received
media does not yet exist; instead, only policies can be used,
which can be made to work in controlled environments.</t>
<t
hangText="Distributing the presentation description to all participants in the group:">To
enable a media receiver to correctly decode the content the media
configuration information needs to be distributed reliably to all
participants. This will most likely require support from an
external protocol.</t>
<t hangText="Passing control of the session:">If it is desired to
pass control of the RTSP session between the participants, some
support will be required by an external protocol to exchange state
information and possibly floor control of who is controlling the
RTSP session.</t>
</list> If there interest in this use case, further work is required
on the necessary extensions.</t>
</section>
<section title="Live Content using Multicast">
<t>This use case in its simplest form does not require any use of RTSP
at all; this is what multicast conferences being announced with <xref
target="RFC2974">SAP</xref> and SDP are intended to handle. However in
use cases where more advanced features like access control to the
multicast session are desired, RTSP could be used for session
establishment.</t>
<t>A client desiring to join a live multicasted media session with
cryptographic (encryption) access control could use RTSP in the
following way. The source of the session announces the session and
gives all interested an RTSP URI. The client connects to the server
and requests the presentation description, allowing configuration for
reception of the media. In this step it is possible for the client to
use secured transport and any desired level of authentication; for
example, for billing or access control. An RTSP link also allows for
load balancing between multiple servers.</t>
<t>If these were the only goals, they could be achieved by simply
using HTTP. However, for cases where the sender likes to keep track of
each individual receiver of a session, and possibly use the session as
a side channel for distributing key-updates or other information on a
per-receiver basis, and the full set of receivers is not know prior to
the session start, the state establishment that RTSP provides can be
beneficial. In this case a client would establish an RTSP session for
this multicast group with the RTSP server. The RTSP server will not
transmit any media, but instead will point to the multicast group. The
client and server will be able to keep the session alive for as long
as the receiver participates in the session thus enabling, for
example, the server to push updates to the client.</t>
<t>This use case will most likely not be able to be implemented
without some extensions to the server-to-client push mechanism. Here
the PLAY_NOTIFY method (see <xref target="sec_PLAY_NOTIFY"></xref>)
with a suitable extension could provide clear benefits.</t>
</section>
</section>
<section anchor="sec_parameters" title="Protocol Parameters">
<section title="RTSP Version">
<t>HTTP specification section [H3.1] applies, with "HTTP" replaced by
"RTSP". This specification defines version 2.0 of RTSP.</t>
</section>
<section anchor="sec_url" title="RTSP IRI and URI">
<t>RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps"
and "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 defined in RTSP 1.0. The "rtspu" scheme indicates undefined
transport of the RTSP messages over unreliable transport (UDP). The
syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0.</t>
<t>This specification also defines the format of the RTSP IRI <xref
target="RFC3987"></xref> that can be used as RTSP resource identifiers
and locators, in web pages, user interfaces, on paper, etc. However,
the RTSP request message format only allows usage of the absolute URI
format. The RTSP IRI format SHALL use the rules and transformation for
IRIs defined in <xref target="RFC3987"></xref>. This way RTSP 2.0 URIs
for request can be produced from an RTSP IRI.</t>
<t>The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in <xref target="RFC3986"></xref> and RFC <xref
target="RFC3987"></xref>: <list hangIndent="3" style="symbols">
<t>An absolute URI requires the authority part; i.e., a host
identity must be provided.</t>
<t>Parameters in the path element are prefixed with the reserved
separator ";".</t>
</list> The RTSP URI and IRI is case sensitive, with the exception
of those parts that <xref target="RFC3986"></xref> and <xref
target="RFC3987"></xref> defines as case-insensitive; for example, the
scheme and host part.</t>
<t>The fragment identifier is used as defined in sections 3.5 and 4.3
of <xref target="RFC3986"></xref>, i.e. the fragment is to be stripped
from the URI by the requestor and not included in the request. The
user agent also needs to interpret the value of the fragment based on
the media type the request relates to; i.e., the media type indicated
in Content-Type header in the response to DESCRIBE.</t>
<t>The syntax of any URI query string is unspecified and responder
(usually the server) specific. The query is, from the requestor's
perspective, an opaque string and needs to be handled as such.</t>
<t>The URI scheme "rtsp" requires that commands are issued via a
reliable protocol (within the Internet, TCP), while the scheme "rtsps"
identifies a reliable transport using secure transport (TLS <xref
target="RFC4346"></xref>, see (<xref
target="sec_security-framework"></xref>).</t>
<t>For the scheme "rtsp", if no port number is provided in the
authority part of the URI port number 554 SHALL be used. For the
scheme "rtsps", the TCP port 322 is registered and SHALL be
assumed.</t>
<t>A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions of URIs
<xref target="RFC3986"></xref>. URIs may refer to a stream or an
aggregate of streams; i.e., a presentation. Accordingly, requests
described in (<xref target="sec_methods"></xref>) can apply to either
the whole presentation or an individual stream within the
presentation. Note that some request methods can only be applied to
streams, not presentations, and vice versa.</t>
<t>For example, the RTSP URI: <list style="hanging">
<t>rtsp://media.example.com:554/twister/audiotrack</t>
</list> may identify the audio stream within the presentation
"twister", which can be controlled via RTSP requests issued over a TCP
connection to port 554 of host media.example.com.</t>
<t>Also, the RTSP URI: <list style="hanging">
<t>rtsp://media.example.com:554/twister</t>
</list> identifies the presentation "twister", which may be composed
of audio and video streams, but could also be something else like a
random media redirector.</t>
<t><list style="hanging">
<t>This does not imply a standard way to reference streams in
URIs. The presentation description defines the hierarchical
relationships in the presentation and the URIs for the individual
streams. A presentation description may name a stream "a.mov" and
the whole presentation "b.mov".</t>
</list></t>
<t>The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server.</t>
<t><list style="hanging">
<t>This decoupling also allows presentation descriptions to be
used with non-RTSP media control protocols simply by replacing the
scheme in the URI.</t>
</list></t>
</section>
<section anchor="sec_session-id" title="Session Identifiers">
<t>Session identifiers are strings of any arbitrary length but with a
minimum length of 8 characters. A session identifier MUST be chosen
cryptographically random (see <xref target="RFC4086"></xref>) and MUST
be at least 8 characters long (can contain a maximum of 48 bits of
entropy) to make guessing it more difficult. It is RECOMMENDED that it
contains 128 bits of entropy, i.e. approxamitely 22 characters from a
high quality generator. (see <xref target="sec_security"></xref>.)
However, it needs to be noted that the session identifier does not
provide any security against session hijacking unless it is kept
confidential between client, server and trusted proxies.</t>
</section>
<section anchor="sec_smpte" title="SMPTE Relative Timestamps">
<t>A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format <list
style="hanging">
<t>hours:minutes:seconds:frames.subframes,</t>
</list> with the origin at the start of the clip. The default smpte
format is "SMPTE 30 drop" format, with frame rate is 29.97 frames per
second. Other SMPTE codes MAY be supported (such as "SMPTE 25")
through the use of alternative use of "smpte-type". For SMPTE 30, the
"frames" field in the time value can assume the values 0 through 29.
The difference between 30 and 29.97 frames per second is handled by
dropping the first two frame indices (values 00 and 01) of every
minute, except every tenth minute. If the frame and the subframe
values are zero, they may be omitted. Subframes are measured in
one-hundredth of a frame.</t>
<t>Examples: <figure>
<artwork><![CDATA[
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01
]]></artwork>
</figure></t>
</section>
<section anchor="sec_npt" title="Normal Play Time">
<t>Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused with
the Network Time Protocol (NTP) <xref target="RFC1305"></xref>. The
timestamp consists of a decimal fraction. The part left of the decimal
may be expressed in either seconds or hours, minutes, and seconds. The
part right of the decimal point measures fractions of a second.</t>
<t>The beginning of a presentation corresponds to 0.0 seconds.
Negative values are not defined. The special constant "now" is defined
as the current instant of a live event. It MAY only be used for live
events, and SHALL NOT be used for on-demand (i.e., non-live)
content.</t>
<t>NPT is defined as in DSM-CC <xref
target="ISO.13818-6.1995"></xref>: "Intuitively, NPT is the clock the
viewer associates with a program. It is often digitally displayed on a
VCR. NPT advances normally when in normal play mode (scale = 1),
advances at a faster rate when in fast scan forward (high positive
scale ratio), decrements when in scan reverse (high negative scale
ratio) and is fixed in pause mode. NPT is (logically) equivalent to
SMPTE time codes."</t>
<t>Examples: <figure>
<artwork><![CDATA[
npt=123.45-125
npt=12:05:35.3-
npt=now-
]]></artwork>
</figure></t>
<t><list style="hanging">
<t>The syntax conforms to ISO 8601 <xref
target="ISO.8601.2000"></xref>. The npt-sec notation is optimized
for automatic generation, the npt-hhmmss notation for consumption
by human readers. The "now" constant allows clients to request to
receive the live feed rather than the stored or time-delayed
version. This is needed since neither absolute time nor zero time
are appropriate for this case.</t>
</list></t>
</section>
<section anchor="sec_clock" title="Absolute Time">
<t>Absolute time is expressed as ISO 8601 <xref
target="ISO.8601.2000"></xref> timestamps, using UTC (GMT). Fractions
of a second may be indicated.</t>
<t>Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC: <figure>
<artwork><![CDATA[
19961108T143720.25Z
]]></artwork>
</figure></t>
</section>
<section anchor="sec_feature_tags" title="Feature-tags">
<t>Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (<xref
target="sec_Require"></xref>), Proxy-Require (<xref
target="sec_Proxy-Require"></xref>), Proxy-Supported (<xref
target="sec_Proxy-Supported"></xref>), and Unsupported (<xref
target="sec_Unsupported"></xref>) header fields.</t>
<t>A feature-tag definition MUST indicate which combination of
clients, servers or proxies they applies to.</t>
<t>The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose inventor
can be reached at "example.com"), or register the new feature-tag with
the Internet Assigned Numbers Authority (IANA) (see IANA <xref
target="sec_IANA"></xref>).</t>
<t>The usage of feature-tags is further described in <xref
target="sec_capability"></xref> that deals with capability
handling.</t>
</section>
<section anchor="sec_entity-tags" title="Entity Tags">
<t>Entity tags are opaque strings that are used to compare two
entities from the same resource, for example in caches or to optimize
setup after a redirect. Further explanation is present in [H3.11]. For
an explanation of how to compare entity tags see [H13.3]. Entity tags
can be carried in the ETag header (see <xref
target="sec_ETag"></xref>) or in SDP (see <xref
target="sec_sdp-etag"></xref>).</t>
<t>Entity tags are used in RTSP to make some methods conditional. The
methods are made conditional through the inclusion of headers, see
<xref target="sec_If-Match"></xref> and <xref
target="sec_If-None-Match"></xref>. Note that RTSP entity tags apply
to the complete presentation; i.e., both the session description and
the individual media streams. Thus entity tags can be used to verify
at setup time after a redirect that the same session description
applies to the media at the new location using the If-Match
header.</t>
</section>
</section>
<section anchor="sec_message" title="RTSP Message">
<t>RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 3629 <xref target="RFC3629"></xref>). Lines SHALL be
terminated by CRLF.</t>
<t><list style="hanging">
<t>Text-based protocols make it easier to add optional parameters in
a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if done carefully, also allow easy
implementation of research prototypes in scripting languages such as
Tcl, Visual Basic and Perl.</t>
</list></t>
<t>The ISO 10646 character set avoids tricky character set switching,
but is invisible to the application as long as US-ASCII is being used.
This is also the encoding used for <xref target="RFC3550">RTCP</xref>.
ISO 8859-1 translates directly into Unicode with a high-order octet of
zero. ISO 8859-1 characters with the most-significant bit set are
represented as 1100001x 10xxxxxx. (See RFC 3629 <xref
target="RFC3629"></xref>)</t>
<t>Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent unless
otherwise noted. Methods are also designed to require little or no state
maintenance at the media server.</t>
<section anchor="sec_message-types" title="Message Types">
<t>RTSP messages consist of requests from client to server or server
to client and responses in the reverse direction. Request <xref
target="sec_request"></xref> and Response <xref
target="sec_response"></xref> messages use the generic message format
of RFC 822 [9] for transferring entities (the payload of the message).
Both types of message consist of a start-line, zero or more header
fields (also known as "headers"), an empty line (i.e., a line with
nothing preceding the CRLF) indicating the end of the header fields,
and possibly a message-body.</t>
<t><figure>
<artwork><![CDATA[generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
]]></artwork>
</figure>In the interest of robustness, servers SHOULD ignore any
empty line(s) received where a Request-Line is expected. In other
words, if the server is reading the protocol stream at the beginning
of a message and receives a CRLF first, it should ignore the CRLF.</t>
</section>
<section anchor="sec_message-headers" title="Message Headers">
<t>See [H4.2].</t>
</section>
<section anchor="sec_message-body" title="Message Body">
<t>See [H4.3].</t>
<t>Unlike HTTP, the presence of a message-body in either a request or
a response MUST be signaled by the inclusion of a Content-Length
header field (see <xref target="sec_Content-Length"></xref>).</t>
</section>
<section title="Message Length">
<t>When a message body is included with a message, the length of that
body is determined by one of the following (in order of precedence):
<list style="numbers">
<t>Any response message which MUST NOT include a message body
(such as the 1xx, 204, and 304 responses) is always terminated by
the first empty line after the header fields, regardless of the
entity-header fields present in the message. (Note: An empty line
is a line with nothing preceding the CRLF.)</t>
<t>If a Content-Length header field (<xref
target="sec_Content-Length"></xref>) is present, its value in
bytes represents the length of the message-body. If this header
field is not present, a value of zero is assumed.</t>
</list> Unlike an HTTP message, an RTSP message MUST contain a
Content-Length header field whenever it contains a message body. Note
that RTSP does not support the HTTP/1.1 "chunked" transfer coding (see
[H3.6.1]).</t>
<t><list style="hanging">
<t>Given the moderate length of presentation descriptions
returned, the server should always be able to determine its
length, even if it is generated dynamically, making the chunked
transfer encoding unnecessary.</t>
</list></t>
</section>
</section>
<section anchor="sec_general-header" title="General Header Fields">
<t>See [H4.5], except that the Pragma, Trailer, Transfer-Encoding,
Upgrade, and Warning headers are not defined. RTSP further defines the
CSeq, Pipelined-Requests, Proxy-Supported and Timestamp headers. The
general headers are listed in <xref
target="tab_headers-general"></xref>:</t>
<texttable anchor="tab_headers-general"
title="The general headers used in RTSP">
<preamble></preamble>
<ttcol align="left">Header Name</ttcol>
<ttcol align="left">Defined in Section</ttcol>
<c>Cache-Control</c>
<c><xref target="sec_Cache-Control"></xref></c>
<c>Connection</c>
<c><xref target="sec_Connection"></xref></c>
<c>CSeq</c>
<c><xref target="sec_CSeq"></xref></c>
<c>Date</c>
<c><xref target="sec_Date"></xref></c>
<c>Media-Properties</c>
<c><xref target="sec_Media-Properties"></xref></c>
<c>Media-Range</c>
<c><xref target="sec_Media-Range"></xref></c>
<c>Pipelined-Requests</c>
<c><xref target="sec_Pipelined-Requests"></xref></c>
<c>Proxy-Supported</c>
<c><xref target="sec_Proxy-Supported"></xref></c>
<c>Seek-Style</c>
<c><xref target="sec_Seek-Style"></xref></c>
<c>Supported</c>
<c><xref target="sec_Supported"></xref></c>
<c>Timestamp</c>
<c><xref target="sec_Timestamp"></xref></c>
<c>Via</c>
<c><xref target="sec_Via"></xref></c>
</texttable>
</section>
<section anchor="sec_request" title="Request">
<t>A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: <list
hangIndent="3" style="symbols">
<t>Request line, containing the method to be applied to the
resource, the identifier of the resource, and the protocol version
in use;</t>
<t>Zero or more Header lines, that can be of the following types:
general (<xref target="sec_general-header"></xref>), request (<xref
target="sec_request-header"></xref>), or entity (<xref
target="sec_entity-header"></xref>);</t>
<t>One empty line (CRLF) to indicate the end of the header
section;</t>
<t>Optionally a message body (entity), consisting of one or more
lines. The length of the message body in bytes is indicated by the
Content-Length entity header.</t>
</list></t>
<section anchor="sec_request-line" title="Request Line">
<t>The request line provides the key information about the request:
what method, on what resources and using which RTSP version. The
methods that are defined by this specification are listed in <xref
target="tab_request-methods" />. <texttable
anchor="tab_request-methods" title="The RTSP Methods">
<preamble />
<ttcol align="left">Method</ttcol>
<ttcol align="left">Defined in Section</ttcol>
<c>DESCRIBE</c>
<c>
<xref target="sec_DESCRIBE" />
</c>
<c>GET_PARAMETER</c>
<c>
<xref target="sec_GET_PARAMETER" />
</c>
<c>OPTIONS</c>
<c>
<xref target="sec_OPTIONS" />
</c>
<c>PAUSE</c>
<c>
<xref target="sec_PAUSE" />
</c>
<c>PLAY</c>
<c>
<xref target="sec_PLAY" />
</c>
<c>PLAY_NOTIFY</c>
<c>
<xref target="sec_PLAY_NOTIFY" />
</c>
<c>REDIRECT</c>
<c>
<xref target="sec_REDIRECT" />
</c>
<c>SETUP</c>
<c>
<xref target="sec_SETUP" />
</c>
<c>SET_PARAMETER</c>
<c>
<xref target="sec_SET_PARAMETER" />
</c>
<c>TEARDOWN</c>
<c>
<xref target="sec_TEARDOWN" />
</c>
</texttable></t>
<t>The syntax of the RTSP request line is the following: <list
style="hanging">
<t><Method> <Request-URI> <RTSP-Version>
CRLF</t>
</list> Note: This syntax cannot be freely changed in future
versions of RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the
message.</t>
<t>In contrast to HTTP/1.1 <xref target="RFC2616"></xref>, RTSP
requests identify the resource through an absolute RTSP URI (scheme,
host, and port) (see <xref target="sec_url"></xref>) rather than just
the absolute path.</t>
<t><list style="hanging">
<t>HTTP/1.1 requires servers to understand the absolute URI, but
clients are supposed to use the Host request header. This is
purely needed for backward-compatibility with HTTP/1.0 servers, a
consideration that does not apply to RTSP.</t>
</list></t>
<t>An asterisk "*" can be used instead of an absolute URI in the
Request-URI part to indicate that the request does not apply to a
particular resource, but to the server or proxy itself, and is only
allowed when the request method does not necessarily apply to a
resource.</t>
<t>For example: <list style="hanging">
<t>OPTIONS * RTSP/2.0</t>
</list></t>
<t>An OPTIONS in this form will determine the capabilities of the
server or the proxy that first receives the request. If the capability
of the specific server needs to be determined, without regard to the
capability of an intervening proxy, the server should be addressed
explicitly with an absolute URI that contains the server's
address.</t>
<t>For example: <list style="hanging">
<t>OPTIONS rtsp://example.com RTSP/2.0</t>
</list></t>
</section>
<section anchor="sec_request-header" title="Request Header Fields">
<t>The RTSP headers in <xref target="tab_request-header" /> can be
included in a request, as request headers, to modify the specifics of
the request. Some of these headers may also be used in the response to
a request, as response headers, to modify the specifics of a response
(<xref target="sec_response-header" />). <texttable
anchor="tab_request-header" title="The RTSP request headers">
<preamble />
<ttcol align="left">Header</ttcol>
<ttcol align="left">Defined in Section</ttcol>
<c>Accept</c>
<c>
<xref target="sec_Accept" />
</c>
<c>Accept-Credentials</c>
<c>
<xref target="sec_Accept-Credentials" />
</c>
<c>Accept-Encoding</c>
<c>
<xref target="sec_Accept-Encoding" />
</c>
<c>Accept-Language</c>
<c>
<xref target="sec_Accept-Language" />
</c>
<c>Authorization</c>
<c>
<xref target="sec_Authorization" />
</c>
<c>Bandwidth</c>
<c>
<xref target="sec_Bandwidth" />
</c>
<c>Blocksize</c>
<c>
<xref target="sec_Blocksize" />
</c>
<c>From</c>
<c>
<xref target="sec_From" />
</c>
<c>If-Match</c>
<c>
<xref target="sec_If-Match" />
</c>
<c>If-Modified-Since</c>
<c>
<xref target="sec_If-Modified-Since" />
</c>
<c>If-None-Match</c>
<c>
<xref target="sec_If-None-Match" />
</c>
<c>Notify-Reason</c>
<c>
<xref target="sec_Notify-Reason" />
</c>
<c>Proxy-Require</c>
<c>
<xref target="sec_Proxy-Require" />
</c>
<c>Range</c>
<c>
<xref target="sec_Range" />
</c>
<c>Referer</c>
<c>
<xref target="sec_Referer" />
</c>
<c>Request-Status</c>
<c>
<xref target="sec_Request-Status" />
</c>
<c>Require</c>
<c>
<xref target="sec_Require" />
</c>
<c>Scale</c>
<c>
<xref target="sec_Scale" />
</c>
<c>Session</c>
<c>
<xref target="sec_Session" />
</c>
<c>Speed</c>
<c>
<xref target="sec_Speed" />
</c>
<c>Supported</c>
<c>
<xref target="sec_Supported" />
</c>
<c>Transport</c>
<c>
<xref target="sec_Transport" />
</c>
<c>User-Agent</c>
<c>
<xref target="sec_User-Agent" />
</c>
</texttable> Detailed headers definition are provided in <xref
target="sec_headers" />.</t>
<t>New request headers may be defined. If the receiver of the request
is required to understand the request header, the request MUST include
a corresponding feature tag in a Require or Proxy-Require header to
ensure the processing of the header. actually happens.</t>
</section>
</section>
<!-- title="Request" -->
<section anchor="sec_response" title="Response">
<t>[H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some of
the HTTP codes. The valid response codes and the methods they can be
used with are listed in <xref target="tab_status"></xref>.</t>
<t>After receiving and interpreting a request message, the recipient
responds with an RTSP response message.</t>
<section anchor="sec_status-line" title="Status-Line">
<t>The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and the
textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the final
CRLF sequence.</t>
<t><RTSP-Version> SP <Status-Code> SP
<Reason-Phrase> CRLF</t>
<section anchor="sec_status-code"
title="Status Code and Reason Phrase">
<t>The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully
defined in <xref target="sec_status"></xref>. The Reason-Phrase is
intended to give a short textual description of the Status-Code. The
Status-Code is intended for use by automata and the Reason-Phrase is
intended for the human user. The client is not required to examine
or display the Reason-Phrase.</t>
<t>The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. There are 5
values for the first digit: <list hangIndent="6" style="hanging">
<t hangText="1xx:">Informational - Request received, continuing
process</t>
<t hangText="2xx:">Success - The action was successfully
received, understood, and accepted</t>
<t hangText="3rr:">Redirection - Further action needs to be
taken in order to complete the request</t>
<t hangText="4xx:">Client Error - The request contains bad
syntax or cannot be fulfilled</t>
<t hangText="5xx:">Server Error - The server failed to fulfill
an apparently valid request</t>
</list> The individual values of the numeric status codes defined
for RTSP/2.0, and an example set of corresponding Reason-Phrases,
are presented in <xref target="tab_status"></xref>. The reason
phrases listed here are only recommended; they may be replaced by
local equivalents without affecting the protocol. Note that RTSP
adopts most HTTP/1.1 <xref target="RFC2616"></xref> status codes and
adds RTSP-specific status codes starting at x50 to avoid conflicts
with newly defined HTTP status codes.</t>
<t>RTSP status codes are extensible. RTSP applications are not
required to understand the meaning of all registered status codes,
though such understanding is obviously desirable. However,
applications MUST understand the class of any status code, as
indicated by the first digit, and treat any unrecognized response as
being equivalent to the x00 status code of that class, with the
exception that an unrecognized response MUST NOT be cached. For
example, if an unrecognized status code of 431 is received by the
client, it can safely assume that there was something wrong with its
request and treat the response as if it had received a 400 status
code. In such cases, user agents SHOULD present to the user the
entity returned with the response, since that entity is likely to
include human-readable information which will explain the unusual
status. <texttable anchor="tab_status"
title="Status codes and their usage with RTSP methods">
<preamble />
<ttcol align="left">Code</ttcol>
<ttcol align="left">Reason</ttcol>
<ttcol align="left">Method</ttcol>
<c>100</c>
<c>Continue</c>
<c>all</c>
<c />
<c />
<c />
<c>200</c>
<c>OK</c>
<c>all</c>
<c />
<c />
<c />
<c>300</c>
<c>Multiple Choices</c>
<c>all</c>
<c>301</c>
<c>Moved Permanently</c>
<c>all</c>
<c>302</c>
<c>Found</c>
<c>all</c>
<c>303</c>
<c>See Other</c>
<c>all</c>
<c>305</c>
<c>Use Proxy</c>
<c>all</c>
<c />
<c />
<c />
<c>400</c>
<c>Bad Request</c>
<c>all</c>
<c>401</c>
<c>Unauthorized</c>
<c>all</c>
<c>402</c>
<c>Payment Required</c>
<c>all</c>
<c>403</c>
<c>Forbidden</c>
<c>all</c>
<c>404</c>
<c>Not Found</c>
<c>all</c>
<c>405</c>
<c>Method Not Allowed</c>
<c>all</c>
<c>406</c>
<c>Not Acceptable</c>
<c>all</c>
<c>407</c>
<c>Proxy Authentication Required</c>
<c>all</c>
<c>408</c>
<c>Request Timeout</c>
<c>all</c>
<c>410</c>
<c>Gone</c>
<c>all</c>
<c>411</c>
<c>Length Required</c>
<c>all</c>
<c>412</c>
<c>Precondition Failed</c>
<c>DESCRIBE, SETUP</c>
<c>413</c>
<c>Request Entity Too Large</c>
<c>all</c>
<c>414</c>
<c>Request-URI Too Long</c>
<c>all</c>
<c>415</c>
<c>Unsupported Media Type</c>
<c>all</c>
<c>451</c>
<c>Parameter Not Understood</c>
<c>SET_PARAMETER</c>
<c>452</c>
<c>reserved</c>
<c>n/a</c>
<c>453</c>
<c>Not Enough Bandwidth</c>
<c>SETUP</c>
<c>454</c>
<c>Session Not Found</c>
<c>all</c>
<c>455</c>
<c>Method Not Valid In This State</c>
<c>all</c>
<c>456</c>
<c>Header Field Not Valid</c>
<c>all</c>
<c>457</c>
<c>Invalid Range</c>
<c>PLAY, PAUSE</c>
<c>458</c>
<c>Parameter Is Read-Only</c>
<c>SET_PARAMETER</c>
<c>459</c>
<c>Aggregate Operation Not Allowed</c>
<c>all</c>
<c>460</c>
<c>Only Aggregate Operation Allowed</c>
<c>all</c>
<c>461</c>
<c>Unsupported Transport</c>
<c>all</c>
<c>462</c>
<c>Destination Unreachable</c>
<c>all</c>
<c>463</c>
<c>Destination Prohibited</c>
<c>SETUP</c>
<c>464</c>
<c>Data Transport Not Ready Yet</c>
<c>PLAY</c>
<c>465</c>
<c>Notification Reason Unknown</c>
<c>PLAY_NOTIFY</c>
<c>470</c>
<c>Connection Authorization Required</c>
<c>all</c>
<c>471</c>
<c>Connection Credentials not accepted</c>
<c>all</c>
<c>472</c>
<c>Failure to establish secure connection</c>
<c>all</c>
<c />
<c />
<c />
<c>500</c>
<c>Internal Server Error</c>
<c>all</c>
<c>501</c>
<c>Not Implemented</c>
<c>all</c>
<c>502</c>
<c>Bad Gateway</c>
<c>all</c>
<c>503</c>
<c>Service Unavailable</c>
<c>all</c>
<c>504</c>
<c>Gateway Timeout</c>
<c>all</c>
<c>505</c>
<c>RTSP Version Not Supported</c>
<c>all</c>
<c>551</c>
<c>Option not support</c>
<c>all</c>
</texttable></t>
</section>
</section>
<section anchor="sec_response-header" title="Response Header Fields">
<t>The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in
the Status-Line. These header fields give information about the server
and about further access to the resource identified by the
Request-URI. All headers currently classified as response headers are
listed in <xref target="tab_response-header" />. <texttable
anchor="tab_response-header" title="The RTSP response headers">
<preamble />
<ttcol align="left">Header</ttcol>
<ttcol align="left">Defined in Section</ttcol>
<c>Accept-Credentials</c>
<c>
<xref target="sec_Accept-Credentials" />
</c>
<c>Accept-Ranges</c>
<c>
<xref target="sec_Accept-Ranges" />
</c>
<c>Connection-Credentials</c>
<c>
<xref target="sec_Connection-Credentials" />
</c>
<c>ETag</c>
<c>
<xref target="sec_ETag" />
</c>
<c>Location</c>
<c>
<xref target="sec_Location" />
</c>
<c>Proxy-Authenticate</c>
<c>
<xref target="sec_Proxy-Authenticate" />
</c>
<c>Public</c>
<c>
<xref target="sec_Public" />
</c>
<c>Range</c>
<c>
<xref target="sec_Range" />
</c>
<c>Retry-After</c>
<c>
<xref target="sec_Retry-After" />
</c>
<c>RTP-Info</c>
<c>
<xref target="sec_RTP-Info" />
</c>
<c>Scale</c>
<c>
<xref target="sec_Scale" />
</c>
<c>Session</c>
<c>
<xref target="sec_Session" />
</c>
<c>Server</c>
<c>
<xref target="sec_Server" />
</c>
<c>Speed</c>
<c>
<xref target="sec_Speed" />
</c>
<c>Transport</c>
<c>
<xref target="sec_Transport" />
</c>
<c>Unsupported</c>
<c>
<xref target="sec_Unsupported" />
</c>
<c>Vary</c>
<c>
<xref target="sec_Vary" />
</c>
<c>WWW-Authenticate</c>
<c>
<xref target="sec_WWW-Authenticate" />
</c>
</texttable> Response-header field names can be extended reliably
only in combination with a change in the protocol version. However the
usage of feature-tags in the request allows the responding party to
learn the capability of the receiver of the response. New or
experimental header fields MAY be given the semantics of
response-header fields if all parties in the communication recognize
them to be response-header fields. Unrecognized header fields in
responses are treated as entity-header fields.</t>
</section>
</section>
<!-- title="Response" -->
<section anchor="sec_entity" title="Entity">
<t>Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers.</t>
<t>The SET_PARAMETER and GET_PARAMETER request and response, and
DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY also
have an entity.</t>
<t>In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.</t>
<section anchor="sec_entity-header" title="Entity Header Fields">
<t>Entity-header fields define meta-information about the entity-body
or, if no body is present, about the resource identified by the
request. The entity header fields are listed in <xref
target="tab_entity-header-tab" />. <texttable
anchor="tab_entity-header-tab" title="The RTSP entity headers">
<preamble />
<ttcol align="left">Header</ttcol>
<ttcol align="left">Defined in Section</ttcol>
<c>Allow</c>
<c>
<xref target="sec_Allow" />
</c>
<c>Content-Base</c>
<c>
<xref target="sec_Content-Base" />
</c>
<c>Content-Encoding</c>
<c>
<xref target="sec_Content-Encoding" />
</c>
<c>Content-Language</c>
<c>
<xref target="sec_Content-Language" />
</c>
<c>Content-Length</c>
<c>
<xref target="sec_Content-Length" />
</c>
<c>Content-Location</c>
<c>
<xref target="sec_Content-Location" />
</c>
<c>Content-Type</c>
<c>
<xref target="sec_Content-Type" />
</c>
<c>Expires</c>
<c>
<xref target="sec_Expires" />
</c>
<c>Last-Modified</c>
<c>
<xref target="sec_Last-Modified" />
</c>
</texttable> The extension-header mechanism allows additional
entity-header fields to be defined without changing the protocol, but
these fields cannot be assumed to be recognizable by the recipient.
Unrecognized header fields SHOULD be ignored by the recipient and
forwarded by proxies.</t>
</section>
<section title="Entity Body">
<t>See [H7.2] with the addition that an RTSP message with an entity
body MUST include the Content-Type and Content-Length headers.</t>
</section>
</section>
<!-- title="Entity -->
<section anchor="sec_connections" title="Connections">
<t>RTSP requests can be transmitted using the two different connection
scenarios listed below: <list hangIndent="3" style="symbols">
<t>persistent - a transport connection is used for several
request/response transactions;</t>
<t>transient - a transport connection is used for a single
request/response transaction.</t>
</list></t>
<t>RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such as
UDP. However, it was not specified in sufficient detail to allow for
interoperable implementations. In an attempt to reduce complexity and
scope, and due to lack of interest, RTSP 2.0 does not attempt to define
a mechanism for supporting RTSP over UDP or other connectionless
transport protocols. A side-effect of this is that RTSP requests SHALL
NOT be sent to multicast groups since no connection can be established
with a specific receiver in multicast environments.</t>
<t>Certain RTSP headers, such as the CSeq header (<xref
target="sec_CSeq"></xref>), which may appear to be relevant only to
connectionless transport scenarios are still retained and must be
implemented according to the specification. In the case of CSeq, it is
quite useful for matching responses to requests if the requests are
pipelined (see <xref target="Pipelining"></xref>). It is also useful in
proxies for keeping track of the different requests when aggregating
several client requests on a single TCP connection.</t>
<section title="Reliability and Acknowledgements">
<t>When RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level.
Instead, the implementation must rely on the underlying transport to
provide reliability. The RTSP implementation may use any indication of
reception acknowledgement of the message from the underlying transport
protocols to optimize the RTSP behavior.</t>
<t><list style="hanging">
<t>If both the underlying reliable transport such as TCP and the
RTSP application retransmit requests, each packet loss or message
loss may result in two retransmissions. The receiver typically
cannot take advantage of the application-layer retransmission
since the transport stack will not deliver the application-layer
retransmission before the first attempt has reached the receiver.
If the packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the
congestion.</t>
</list></t>
<t>Lack of acknowledgement of an RTSP request should be handled within
the constraints of the connection timeout considerations described
below (<xref target="sec_connection-timeout"></xref>).</t>
</section>
<section anchor="sec_connections-usage" title="Using Connections">
<t>A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST support
RTSP over TCP. The scheme of the RTSP URI (<xref
target="sec_url"></xref>) indicates the default port that the server
will listen on.</t>
<t>A server MUST handle both persistent and transient connections.</t>
<t><list style="hanging">
<t>Transient connections facilitate mechanisms for fault
tolerance. They also allow for application layer mobility. A
server and client pair that support transient connections can
survive the loss of a TCP connection; e.g., due to a NAT timeout.
When the client has discovered that the TCP connection has been
lost, it can set up a new one when there is need to communicate
again.</t>
</list></t>
<t>A persistent connection MAY be used for all transactions between
the server and client, including messages for multiple RTSP sessions.
However a persistent connection MAY also be closed after a few message
exchanges. For example, a client may use a persistent connection for
the initial SETUP and PLAY message exchanges in a session and then
close the connection. Later, when the client wishes to send a new
request, such as a PAUSE for the session, a new connection would be
opened. This connection may either be transient or persistent.</t>
<t>An RTSP agent SHOULD NOT have more than one connection to the
server at any given point. If a client or proxy handles multiple RTSP
sessions on the same server, it SHOULD use only one connection for
managing those sessions.</t>
<t><list style="hanging">
<t>This saves connection resources on the server. It also reduces
complexity by and enabling the server to maintain less state about
its sessions and connections.</t>
</list></t>
<t>Unlike HTTP, RTSP allows a server to send requests to a client.
However, this can be supported only if a client establishes a
persistent connection with the server. In cases where a persistent
connection does not exist between a server and its client, due to the
lack of a signalling channel the server may be forced to drop an RTSP
session without notifying the client. An example of such a case is
when the server desires to send a REDIRECT request for an RTSP session
to the client but is not able to do so because it cannot reach the
client.</t>
<t><list style="hanging">
<t>Without a persistent connection between the client and the
server, the media server has no reliable way of reaching the
client. Also, this is the only way that requests from a server to
its client are likely to traverse firewalls.</t>
</list></t>
<t>In light of the above, it is RECOMMENDED that clients use
persistent connections whenever possible. A client that supports
persistent connections MAY "pipeline" its requests (see <xref
target="Pipelining"></xref>).</t>
</section>
<section title="Closing Connections">
<t>The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being managed
through the connection. The server, however, SHOULD NOT close a
connection until all RTSP sessions being managed through the
connection have been timed out (<xref target="sec_Session"></xref>). A
server SHOULD NOT close a connection immediately after responding to a
session-level TEARDOWN request for the last RTSP session being
controlled through the connection. Instead, it should wait for a
reasonable amount of time for the client to receive the TEARDOWN
response, take appropriate action, and initiate the connection
closing. The server SHOULD wait at least 10 seconds after sending the
TEARDOWN response before closing the connection.</t>
<t><list style="hanging">
<t>This is to ensure that the client has time to issue a SETUP for
a new session on the existing connection after having torn the
last one down. 10 seconds should give the client ample opportunity
get its message to the server.</t>
</list></t>
<t>A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code.</t>
<t><list style="hanging">
<t>Certain error responses such as "460 Only Aggregate Operation
Allowed" (<xref target="sec_error460"></xref>) are used for
negotiating capabilities of a server with respect to content or
other factors. In such cases, it is inefficient for the server to
close a connection on an error response. Also, such behavior would
prevent implementation of advanced/special types of requests or
result in extra overhead for the client when testing for new
features. On the flip side, keeping connections open after sending
an error response poses a Denial of Service security risk (<xref
target="sec_security"></xref>).</t>
</list></t>
<t>If a server closes a connection while the client is attempting to
send a new request, the client will have to close its current
connection, establish a new connection and send its request over the
new connection.</t>
<!-- should the should not read SHOULD NOT? -->
<t>An RTSP message should not be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in <xref
target="sec_message"></xref>.</t>
</section>
<section anchor="sec_connection-timeout"
title="Timing Out Connections and RTSP Messages">
<t>Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requestor) SHOULD wait for a
sufficient time for a response before concluding that the responder
will not be acting upon its request.</t>
<t>A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer
than 5 seconds, it SHOULD send a 100 (Continue) response as soon as
possible. It SHOULD continue sending a 100 response every 5 seconds
thereafter until it is ready to send the final response to the
requestor. After sending a 100 response, the receiver MUST send a
final response indicating the success or failure of the request.</t>
<t>A requestor SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request.
After receiving a 100 response, the requestor SHOULD continue waiting
for further responses. If more than 10 seconds elapses without
receiving any response, the requestor MAY assume that the responder is
unresponsive and abort the connection.</t>
<t>A requestor SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the
responder. The requestor is capable of determining the RTT of the
request/response cycle using the Timestamp header (<xref
target="sec_Timestamp"></xref>) in any RTSP request.</t>
</section>
<section anchor="sec_liveness" title="Showing Liveness">
<t>The mechanisms for showing liveness of the client is, any RTSP
request with a Session header, if RTP & RTCP is used an RTCP
message, or through any other used media protocol capable of
indicating 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 liveness message. The RTSP message may be lost or when using
reliable protocols, such as TCP, the message may take some time to
arrive safely at the receiver. To show liveness between RTSP request
issued to accomplish other things, the following mechanisms can be
used, in descending order of preference: <list hangIndent="6"
style="hanging">
<t hangText="RTCP:">If RTP is used for media transport RTCP SHOULD
be used. If RTCP is used to report transport statistics, it SHALL
also work as keep alive. The server can determine the client by
used network address and port together with the fact that the
client is reporting on the servers SSRC(s). A downside of using
RTCP is that it only gives statistical guarantees to reach the
server. However that probability is so low that it can be ignored
in most cases. For example, a session with 60 seconds timeout and
enough bitrate assigned to RTCP messages to send a message from
client to server on average every 5 seconds. That client have for
a network with 5 % packet loss, the probability to fail showing
liveness sign in that session within the timeout interval of
2.4*E-16. In sessions with shorter timeout times, or much higher
packet loss, or small RTCP bandwidths SHOULD also use any of the
mechanisms below.</t>
<t hangText="SET_PARAMETER:">When using SET_PARAMETER for keep
alive, no body SHOULD be included. This method is the RECOMMENDED
RTSP method to use in request only intended to perform
keep-alive.</t>
<t hangText="OPTIONS:">This method does also work. However it
causes the server to perform more unnecessary processing and
result in bigger responses than necessary for the task. The reason
for this is that the server needs to determine what capabilities
that are associated with the media resource to correctly populate
the Public and Allow headers.</t>
</list></t>
<t>The timeout parameter MAY be included in a SETUP response, and
SHALL NOT be included in requests. The server uses it to indicate to
the client how long the server is prepared to wait between RTSP
commands or other signs of life before closing the session due to lack
of activity (see below and <xref target="sec_machine"></xref>). The
timeout is measured in seconds, with a default of 60 seconds. The
length of the session timeout SHALL NOT be changed in a established
session.</t>
</section>
<section title="Use of IPv6">
<t>Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and
headers.</t>
</section>
</section>
<!-- title="Connections" -->
<section anchor="sec_capability" title="Capability Handling">
<t>This section describes the available capability handling mechanism
which allows RTSP to be extended. Extensions to this version of the
protocol are basically done in two ways. First, new headers can be
added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases.</t>
<t>When a method is added, the involved parties can use the OPTIONS
method to discover wether it is supported. This is done by issuing a
OPTIONS request to the other party. Depending on the URI it will either
apply in regards to a certain media resource, the whole server in
general, or simply the next hop. The OPTIONS response MUST contain a
Public header which declares all methods supported for the indicated
resource.</t>
<t>It is not necessary to use OPTIONS to discover support of a method,
the client could simply try the method. If the receiver of the request
does not support the method it will respond with an error code
indicating the the method is either not implemented (501) or does not
apply for the resource (405). The choice between the two discovery
methods depends on the requirements of the service.</t>
<t>Feature-Tags are defined to handle functionality additions that are
not new methods. Each feature-tag represents a certain block of
functionality. The amount of functionality that a feature-tag represents
can vary significantly. A feature-tag can for example represent the
functionality a single RTSP header provides. Another feature-tag can
represent much more functionality, such as the "play.basic" feature-tag
which represents the minimal playback implementation.</t>
<t>Feature-tags are used to determine wether the client, server or proxy
supports the functionality that is necessary to achieve the desired
service. To determine support of a feature-tag, several different
headers can be used, each explained below: <list hangIndent="6"
style="hanging">
<t hangText="Supported:">The supported header is used to determine
the complete set of functionality that both client and server have.
The intended usage is to determine before one needs to use a
functionality that it is supported. It can be used in any method,
however OPTIONS is the most suitable one as it at the same time
determines all methods that are implemented. When sending a request
the requestor declares all its capabilities by including all
supported feature-tags. This results in that the receiver learns the
requestors feature support. The receiver then includes its set of
features in the response.</t>
<t hangText="Proxy-Supported:">The Proxy-Supported header is used
similar to the Supported header, but instead of giving the supported
functionality of the client or server it provides both the requestor
and the responder a view of what functionality the proxy chain
between the two supports. Proxies are required to add this header
whenever the Supported header is present, but proxies may
independently of the requestor add it.</t>
<t hangText="Require:">The Require header can be included in any
request where the end-point, i.e. the client or server, is required
to understand the feature to correctly perform the request. This
can, for example, be a SETUP request where the server is required to
understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore the end-point
receiving a request containing a Require MUST negatively acknowledge
any feature that it does not understand and not perform the request.
The response in cases where features are not supported are 551
(Option Not Supported). Also the features that are not supported are
given in the Unsupported header in the response.</t>
<t hangText="Proxy-Require:">This method has the same purpose and
workings as Require except that it only applies to proxies and not
the end-point. Features that needs to be supported by both proxies
and end-point needs to be included in both the Require and
Proxy-Require header.</t>
<t hangText="Unsupported:">This header is used in a 551 error
response, to indicate which feature(s) that was not supported. Such
a response is only the result of the usage of the Require and/or
Proxy-Require header where one or more feature where not supported.
This information allows the requestor to make the best of situations
as it knows which features are not supported.</t>
</list></t>
</section>
<section anchor="Pipelining" title="Pipelining Support">
<t>Pipelining is a general method to improve performance of request
response protocols by allowing the requesting entity to have more than
one request outstanding and send them over the same persistent
connection. For RTSP where the relative order of requests will matter it
is important to maintain the order of the requests. Because of this the
the responding entity SHALL process the incoming requests in their
sending order. The sending order can be determined 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 request SHALL also have been
finished before processing the next request from the same entity. The
responses MUST be sent in the order the requests was processed.</t>
<t>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
media playback to be pipelined after each other. This is accomplished by
the utilization of the Pipelined-Requests header (see <xref
target="sec_Pipelined-Requests"></xref>). This header allows a client to
request that two or more requests is to be processed in the same RTSP
session context which 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 to wait for a single response. This speeds up the
initial startup time for an RTSP session with at least one RTT.</t>
<t>If a pipelined request builds on the succesful completion of one or
more prior requests the requestor must verify that all requests were
executed as expected. A common example will be two SETUP requests and a
PLAY request. In case one of the SETUP fails unexpectedly, the PLAY
request can still be succesfully executed. However, not as expected by
the requesting client as only a single media instead of two will be
played. In this case the client can send a PAUSE request, correct the
failing SETUP request and then request it to be played.</t>
</section>
<section anchor="sec_methods" title="Method Definitions">
<t>The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case-sensitive. New
methods may be defined in the future. Method names SHALL NOT start with
a $ character (decimal 24) and MUST be a token as defined by the ABNF
<xref target="RFC5234" /> in the syntax chapter <xref
target="sec_syntax" />. The methods are summarized in <xref
target="tab_methods" />. <texttable anchor="tab_methods"
title="Overview of RTSP methods, their direction, and what objects (P: presentation, S: stream) they operate on. Legend: R=Respond, Sd=Send, Opt: Optional, Req: Required">
<preamble />
<ttcol align="left">method</ttcol>
<ttcol align="left">direction</ttcol>
<ttcol align="left">object</ttcol>
<ttcol align="left">Server req.</ttcol>
<ttcol align="left">Client req.</ttcol>
<c>DESCRIBE</c>
<c>C -> S</c>
<c>P,S</c>
<c>recommended</c>
<c>recommended</c>
<c>GET_PARAMETER</c>
<c>C -> S</c>
<c>P,S</c>
<c>optional</c>
<c>optional</c>
<c>
<!--GET_PARAMETER-->
</c>
<c>S -> C</c>
<c />
<c />
<c />
<c>OPTIONS</c>
<c>C -> S</c>
<c>P,S</c>
<c>R=Req, Sd=Opt</c>
<c>Sd=Req, R=Opt</c>
<c>
<!--OPTIONS-->
</c>
<c>S -> C</c>
<c />
<c />
<c />
<c>PAUSE</c>
<c>C -> S</c>
<c>P,S</c>
<c>required</c>
<c>required</c>
<c>PLAY</c>
<c>C -> S</c>
<c>P,S</c>
<c>required</c>
<c>required</c>
<c>PLAY_NOTIFY</c>
<c>S -> C</c>
<c>P,S</c>
<c>required</c>
<c>required</c>
<c>REDIRECT</c>
<c>S -> C</c>
<c>P,S</c>
<c>optional</c>
<c>required</c>
<c>SETUP</c>
<c>C -> S</c>
<c>S</c>
<c>required</c>
<c>required</c>
<c>SET_PARAMETER</c>
<c>C -> S</c>
<c>P,S</c>
<c>required</c>
<c>optional</c>
<c>
<!--SET_PARAMETER-->
</c>
<c>S -> C</c>
<c />
<c />
<c />
<c>TEARDOWN</c>
<c>C -> S</c>
<c>P,S</c>
<c>required</c>
<c>required</c>
</texttable> <list style="hanging">
<t>Note on <xref target="tab_methods" />: GET_PARAMETER is
recommended, but not required. For example, a fully functional
server can be built to deliver media without any parameters.
SET_PARAMETER is required however due to its usage for keep-alive.
PAUSE is now required due to that it is the only way of getting out
of the state machines play state without terminating the whole
session.</t>
</list></t>
<t>If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD NOT
try this method again for the given agent / resource combination.</t>
<section anchor="sec_OPTIONS" title="OPTIONS">
<t>The semantics of the RTSP OPTIONS method is equivalent to that of
the HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS
is bi-directional, in that a client can request it to a server and
vice versa. A client MUST implement the capability to send an OPTIONS
request and a server or a proxy MUST implement the capability to
respond to an OPTIONS request. The client, server or proxy MAY also
implement the converse of their required capability.</t>
<t>An OPTIONS request may be issued at any time. Such a request does
not modify the session state. However, it may prolong the session
lifespan (see below). The URI in an OPTIONS request determines the
scope of the request and the corresponding response. If the
Request-URI refers to a specific media resource on a given host, the
scope is limited to the set of methods supported for that media
resource by the indicated RTSP agent. A Request-URI with only the host
address limits the scope to the specified RTSP agent's general
capabilities without regard to any specific media. If the Request-URI
is an asterisk ("*"), the scope is limited to the general capabilities
of the next hop (i.e. the RTSP agent in direct communication with the
request sender).</t>
<t>Regardless of scope of the request, the Public header MUST always
be included in the OPTIONS response listing the methods that are
supported by the responding RTSP agent. In addition, if the scope of
the request is limited to a media resource, the Allow header MUST be
included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely matches
the set in the Public header. If the given resource is not available,
the RTSP agent SHOULD return an appropriate response code such as 3rr
or 4xx. The Supported header MAY be included in the request to query
the set of features that are supported by the responding RTSP
agent.</t>
<t>The OPTIONS method can be used to keep an RTSP session alive.
However, it is not the preferred means of session keep-alive
signalling, see <xref target="sec_Session"></xref>. An OPTIONS request
intended for keeping alive an RTSP session MUST include the Session
header with the associated session ID. Such a request SHOULD also use
the media or the aggregated control URI as the Request-URI.</t>
<t>Example: <figure>
<artwork><![CDATA[
C->S: OPTIONS * RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Require:
Proxy-Require: gzipped-messages
Supported: play.basic
S->C: RTSP/2.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Supported: play.basic, implicit-play, gzipped-messages
Server: PhonyServer/1.1
]]></artwork>
</figure></t>
<t>Note that some of the feature-tags in Require and Proxy-Require are
fictional features.</t>
</section>
<section anchor="sec_DESCRIBE" title="DESCRIBE">
<t>The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The client
MAY include the Accept header in the request to list the description
formats that it understands. The server SHALL respond with a
description of the requested resource and return the description in
the entity of the response. The DESCRIBE reply-response pair
constitutes the media initialization phase of RTSP.</t>
<t>Example: <figure>
<artwork><![CDATA[
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Content-Type: application/sdp
Content-Length: 367
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=application 32416 UDP WB
a=orient:portrait
]]></artwork>
</figure></t>
<t>The DESCRIBE response SHOULD contain all media initialization
information for the resource(s) that it describes. Servers SHOULD NOT
use the DESCRIBE response as a means of media indirection by having
the description point at another server, instead usage of 3rr
responses are recommended.</t>
<t><list style="hanging">
<t>By forcing a DESCRIBE response to contain all media
initialization for the set of streams that it describes, and
discouraging the use of DESCRIBE for media indirection, any
looping problems can be avoided that might have resulted from
other approaches.</t>
</list></t>
<t>Media initialization is a requirement for any RTSP-based system,
but the RTSP specification does not dictate that this is required to
be done via the DESCRIBE method. There are three ways that an RTSP
client may receive initialization information: <list hangIndent="3"
style="symbols">
<t>via an RTSP DESCRIBE request</t>
<t>via some other protocol (HTTP, email attachment, etc.)</t>
<t>via some form of a user interface</t>
</list></t>
<t>If a client obtains a valid description from an alternate source,
the client MAY use this description for initialization purposes
without issuing a DESCRIBE request for the same media.</t>
<t>It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to act
as "helper applications" that accept a media initialization file from
a user interface, and/or other means that are appropriate to the
operating environment of the clients.</t>
</section>
<section anchor="sec_SETUP" title="SETUP">
<t>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
different cases; Create an RTSP session and change the transport
parameters of already set up media stream. SETUP can be used in all
three states; INIT, and READY, for both purposes and in PLAY to change
the transport parameters. There is also a third possibile 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 session, when
the session is in PLAY state, is unspecified.</t>
<t>The Transport header, see <xref target="sec_Transport"></xref>,
specifies the transport parameters acceptable to the client for data
transmission; the response will contain the transport parameters
selected by the server. This allows the client to enumerate in
descending order of preference the transport mechanisms and parameters
acceptable to it, while the server can select the most appropriate. It
is expected that the session description format used will enable the
client to select a limited number possible configurations that are
offered to the server to choose from. All transport related parameters
shall be included in the Transport header, the use of other headers
for this purpose is discouraged due to middleboxes, such as firewalls
or NATs.</t>
<t>For the benefit of any intervening firewalls, a client SHALL
indicate the known transport parameters, even if it has no influence
over these parameters, for example, where the server advertises a
fixed multicast address as destination.</t>
<t><list style="hanging">
<t>Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media
initialization.</t>
</list></t>
<t>The client SHALL include the Accept-Ranges header in the request
indicating all supported unit formats in the Range header. This allows
the server to know which format it may use in future session related
responses, such as PLAY response without any range in the request. If
the client does not support a time format necessary for the
presentation the server SHALL respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource.</t>
<t>In a SETUP response the server SHALL include the Accept-Ranges
header (see <xref target="sec_Accept-Ranges"></xref>) to indicate
which time formats that are acceptable to use for this media
resource.</t>
<t>The SETUP response 200 OK SHALL include the Media-Properties header
(see <xref target="sec_Media-Properties"></xref> ). The combination of
the parameters of the Media-Properties header indicate the nature of
the content (see also <xref
target="sec_Media-Properties-Intro"></xref>). For example, a live
stream with time shifting is indicated by<list style="symbols">
<t>Random Access set to Random-Access,</t>
<t>Content Modifications set to Time Progressing,</t>
<t>Retention set to Time-Duration (with specific recording window
time value).</t>
</list></t>
<t>The SETUP response 200 OK SHALL include the Media-Range header (see
<xref target="sec_Media-Range"></xref>) if the media is
Time-Progressing.</t>
<t>A basic example for SETUP:<figure>
<artwork><![CDATA[
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1
Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589";
src_addr="192.0.2.241:6256"/"192.0.2.241:6257";
ssrc=2A3F93ED
Accept-Ranges: NPT
Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0
Media-Range: npt=0-2893.23]]></artwork>
</figure></t>
<t>In the above example the client wants to create an RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". The
transport parameters acceptable to the client is either RTP/AVP/UDP
(UDP per default) to be received on client port 4588 and 4589 or
RTP/AVP interleaved on the RTSP control channel. The server selects
the RTP/AVP/UDP transport and adds the ports it will send and received
RTP and RTCP from, and the RTP SSRC that will be used by the
server.</t>
<t>The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes
a session identifier, in which case the server MUST bundle this setup
request into the existing session (aggregated session) or return error
459 (Aggregate Operation Not Allowed) (see <xref
target="sec_error459"></xref>). An Aggregate control URI MUST be used
to control an aggregated session. This URI MUST be different from the
stream control URIs of the individual media streams included in the
aggregate. The Aggregate control URI is to be specified by the session
description if the server supports aggregated control and aggregated
control is desired for the session. However even if aggregated control
is offered the client MAY chose to not set up the session in
aggregated control. If an Aggregate control URI is not specified in
the session description, it is normally an indication that
non-aggregated control should be used. The SETUP of media streams in
an aggregate which has not been given an aggregated control URI is
unspecified.</t>
<t><list style="hanging">
<t>While the session ID sometimes has enough information for
aggregate control of a session, the Aggregate control URI is still
important for some methods such as SET_PARAMETER where the control
URI enables the resource in question to be easily identified. The
Aggregate control URI is also useful for proxies, enabling them to
route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was
operating on.</t>
</list></t>
<t>A session will exist until it is either removed by a TEARDOWN
request or is timed-out by the server. The server MAY remove a session
that has not demonstrated liveness signs from the client(s) within a
certain timeout period. The default timeout value is 60 seconds; the
server MAY set this to a different value and indicate so in the
timeout field of the Session header in the SETUP response. For further
discussion see <xref target="sec_Session"></xref>. Signs of liveness
for an RTSP session are: <list hangIndent="3" style="symbols">
<t>Any RTSP request from a client(s) which includes a Session
header with that session's ID.</t>
<t>If RTP is used as a transport for the underlying media streams,
an RTCP sender or receiver report from the client(s) for any of
the media streams in that RTSP session. RTCP Sender Reports may
for example be received in sessions where the server is invited
into a conference session and is as valid for keep-alive.</t>
</list></t>
<t>If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated
streams SHALL remain unchanged from their values as if the SETUP
request had never been received by the server.</t>
<section title="Changing Transport Parameters">
<t>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 server MAY allow. If it does not allow changing of
parameters, it MUST respond with error 455 (Method Not Valid In This
State). Reasons to support changing transport parameters, is to
allow for application layer mobility and flexibility to utilize the
best available transport as it becomes available. If a client
receives a 455 when trying to change transport parameters while the
server is in play state, it MAY try to put the server in ready state
using PAUSE, before issuing the SETUP request again. If also that
fails the changing of transport parameters will require that the
client performs a TEARDOWN of the affected media and then setting it
up again. In aggregated session avoiding tearing down all the media
at the same time will avoid the creation of a new session.</t>
<t>All transport parameters MAY be changed. However the primary
usage expected is to either change transport protocol completely,
like switching from Interleaved TCP mode to UDP or vise versa or
change delivery address.</t>
<t>In a SETUP response for a request to change the transport
parameters while in Play state, the server SHALL include the Range
to indicate from what point the new transport parameters are used.
Further, if RTP is used for delivery, the server SHALL also include
the RTP-Info header to indicate from what timestamp and RTP sequence
number the change has taken place. If both RTP-Info and Range is
included in the response the "rtp_time" parameter and range MUST be
for the corresponding time, i.e. be used in the same way as for PLAY
to ensure the correct synchronization information is available.</t>
<t>If the transport parameters change while in PLAY state results in
a change of synchronization related information, for example
changing RTP SSRC, the server MUST provide in the SETUP response the
necessary synchronization information. However the server is
RECOMMENDED to avoid changing the synchronization information if
possible.</t>
</section>
</section>
<section anchor="sec_PLAY" title="PLAY">
<t>This section describes the usage of the PLAY method in general, for
aggregated sessions, and in different usage scenarios.</t>
<section anchor="sec_PLAY_general" title="General Usage">
<t>The PLAY method tells the server to start sending data via the
mechanism specified in SETUP and which part of the media should be
played out. PLAY requests are valid when the session is in READY or
PLAY states. A PLAY request MUST include a Session header to
indicate which session the request applies to.</t>
<t>Upon receipt of the PLAY request, the server SHALL position the
normal play time to the beginning of the range specified in the
received Range header and delivers stream data until the end of the
range if given, or until a new PLAY request is received, else to the
end of the media is reached. To allow for precise composition
multiple ranges MAY be specified in one PLAY Request. The range
values are valid if all given ranges are part of any media within
the aggregate. If a given range value points outside of the media,
the response SHALL be the 457 (Invalid Range) error code.</t>
<t>The below example will first play seconds 10 through 15, then,
immediately following, seconds 20 to 25, and finally seconds 30
through the end. <figure>
<artwork><![CDATA[
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835
Session: 12345678
Range: npt=10-15, npt=20-25, npt=30-
Seek-Style: RAP
User-Agent: PhonyClient/1.2]]></artwork>
</figure></t>
<t>See the description of the PAUSE request for further
examples.</t>
<t>A PLAY request without a Range header is legal. It SHALL start
playing a stream from the beginning (npt=0-) unless the stream has
been paused or is currently playing. If a stream has been paused via
PAUSE, stream delivery resumes at the pause point. If a stream is
currently playing, the new PLAY begins at the current stream
position. The stream SHALL play until the end of the media. The
Range header MUST NOT contain a time parameter. The usage of time in
PLAY method has been deprecated. If a request with time parameter is
received the server SHOULD respond with a 457 (Invalid Range) to
indicate that the time parameter is not supported. If no range is
specified in the request, the start position SHALL still be returned
in the reply. If the medias that are part of an aggregate has
different lengths, the PLAY request SHALL be performed as long as
the given range is valid for any media, for example the longest
media. Media will be sent whenever it is available for the given
play-out point.</t>
<t>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.
npt=0-. If a PLAY request is received without a Range header when
media delivery has stopped at the end, the server SHOULD respond
with a 457 "Invalid Range" error response. In that response the
current pause point in a Range header SHALL be included.</t>
<t>All range specifiers in this specification allow for ranges with
unspecified begin times (e.g. "npt=-30"). When used in a PLAY
request, the server treats this as a request to start/resume
playback from the current pause point, ending at the end time
specified in the Range header. If the pause point is located later
than the given end value, a 457 (Invalid Range) response SHALL be
given.</t>
<t>Server MUST include a "Range" header in any PLAY response. The
response MUST use the same format as the request's range header
contained. If no Range header was in the request, the format used in
any previous PLAY request within the session SHOULD be used. If no
format has been indicated in a previous request the server MAY use
any time format supported by the media and indicated in the
Accept-Ranges header in the SETUP respone. It is RECOMMENDED that
NPT is used if supported by the media.</t>
<t>A PLAY response MAY include a header(s) carrying synchronization
information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage
is needed. For RTP the RTP-Info header is specified, see <xref
target="sec_RTP-Info"></xref>, and used in the following
example.</t>
<t>Here is a simple example for a single audio stream where the
client requests the media starting from 3.52 seconds. The server
sends a 200 OK response with the actual play time (equal to the
requested in this case) and the RTP-Info header that contains the
necessary parameters for the RTP stack.</t>
<figure>
<artwork><![CDATA[C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836
Session: 12345678
Range: npt=3.52-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0
Range: npt=3.52-
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds]]></artwork>
</figure>
<t>For media with random-access, the server MUST reply with the
actual range that will be played back, i.e. for which duration any
media (having content at this time) is delivered. This may differ
from the requested range if alignment of the requested range to
valid frame boundaries is required for the media source. Note that
some media streams in an aggregate may need to be delivered from
even earlier points. Also, some media format have a very long
duration per individual data unit, therefore it might be necessary
for the client to parse the data unit, and select where to start.
The client can express its desired handling by the server by
including the <xref target="sec_Seek-Style">Seek-Style header</xref>
in the PLAY request, if desired.</t>
<t>In the following example the client receives the first media
packet that stretches all the way up and past the requested
playtime. Thus, it is the client's decision if to render to the user
the time between 3.52 and 7.05, or to skip it. In most cases it is
probably most suitable to not render that time period.<figure>
<artwork><![CDATA[C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836
Session: 12345678
Range: npt=7.05- User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0
Range: npt=3.52-
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds]]></artwork>
</figure></t>
<t>After playing the desired range, the presentation does NOT
transition to the READY state, media delivery simply stops. A PAUSE
request MUST be issued before the stream enters the READY state. A
PLAY request while the stream is still in the PLAYING state is
legal, and can be issued without an intervening PAUSE request. Such
a request SHALL replace the current PLAY action with the new one
requested, i.e. being handle the same as the request was received in
ready state. In the case the first time range in Range header has a
open start time (-endtime), the server SHALL continue to play from
where it currently was until the specified end point. This is useful
to change ongoing playback to play another sequence, or end at
another point than in the previous request.</t>
<t>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 headers has been broken into several lines to fit the page.
<figure>
<artwork><![CDATA[
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 833
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0
Range: smpte=0:10:22-0:15:45
RTP-Info:url="rtsp://example.com/twister.en"
ssrc=0D12F123:seq=14783;rtptime=2345962545]]></artwork>
</figure></t>
<t>For playing back a recording of a live presentation, it may be
desirable to use clock units: <figure>
<artwork><![CDATA[C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
CSeq: 835
Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server:PhonyServer 1.0
Range: clock=19961108T142300Z-19961108T143520Z
RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019]]></artwork>
</figure></t>
</section>
<section title="Aggregated Sessions">
<t>PLAY requests can operate on sessions controlling a single media
and on aggregated sessions controlling multiple media.</t>
<t>In an aggregated session the PLAY request MUST contain an
aggregated control URI. A server SHALL responde with error 460 (Only
Aggregate Operation Allowed) if the client PLAY Request-URI is for
one of the media. The media in an aggregate SHALL be played in sync.
If a client wants individual control of the media it needs to use
separate RTSP sessions for each media.</t>
<t>For aggregated sessions where the initial SETUP request (creating
a session) is followed by one or more additional SETUP request, a
PLAY request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This procedure can reduce the
delay from start of session establishment until media play-out has
started with one round trip time. However an client needs to be
aware that using this procedure will result in the playout of the
server state established at the time of processing the PLAY, i.e.,
after the processing of all the requests prior to the PLAY request
in the pipeline. This may not be the intended one due to failure of
any of the prior requests. However a client easily determine this
based on the responses from those requests. In case of failure the
client can halt the media playout using PAUSE and try to establish
the intended state again before issuing another PLAY request.</t>
</section>
<t></t>
<section title="Updating current PLAY Requests">
<t>Clients can issue PLAY request while the stream is In PLAYING
state and thus updating their request. The possibility to replace a
current PLAY request with a new one replaces the following RTSP 1.0
functions based on PLAY in play state: <list hangIndent="3"
style="symbols">
<t>The queued play functionality described in RFC 2326 <xref
target="RFC2326"></xref> is removed and multiple ranges can be
used to achieve a similar functionality in combination with the
possibility to replace previous play messages.</t>
<t>The use of PLAY for keep-alive signaling, i.e. PLAY request
without a range header in PLAY state, has also been deprecated.
Instead a client can use, SET_PARAMETER (recommended) or OPTIONS
(allowed) for keep alive.</t>
</list></t>
<t>The important difference compared to a PLAY request in ready
state is the handling of the current playpoint and how the range
header in request is constructed. The session is actively playing
media and the playpoint will be moving making the exact time a
request will take action is hard to predict. Depending on how the
PLAY header appears two different cases exist: total replacement or
continuation. A total replacement is signalled by having the first
range specification have an explicit start value, e.g. npt=45- or
npt=45-60, in which case the server stops playout at the current
playout point and then starts delivering media according to the
Range 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 the case of continuation the first range specifier has an
open start point and a explict stop value (Z), e.g. npt=-60, which
indicate that it SHALL convert the range specifier being played
prior to this PLAY request (X to Y) into (X to Z) and continue as
this was the request originally played. For both total replacement
and continuation the PLAY request SHALL remove any additional range
specifiers present in the previous request and add any that is
present in the new PLAY request.</t>
<t>An example of this behavior. The server has received requests to
play ranges 10 to 15 and then 13 to 20 (that is, overlapping
ranges). If the new PLAY request arrives at the server 4 seconds
after the previous one, it will take effect while the server plays
the first range (10-15). Thus changing the behavior of this range to
continue to play to 25 seconds, i.e. the equivalent single request
would be PLAY with range: npt=10-25. Note that the second range
(13-20) is deleted and never comes into effect. If the new PLAY
request would arrive as the second range in the first request was
playing (13-20 and shown below), then the equivalent single request
would be play with range:npt=10-15,npt=13-25.</t>
<t><figure>
<artwork><![CDATA[ C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: 12345678
Range: npt=10-15, npt=13-20
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0
Range: npt=10-15, npt=13-20
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: 12345678
Range: npt=-25
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: Thu, 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0
Range: npt=14-25
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
Session: 12345678]]></artwork>
</figure></t>
</section>
<t></t>
<section title="Playing On-Demand Media">
<t>On-demand media is indicated by the content of the
Media-Properties header in the SETUP response by (see also <xref
target="sec_Media-Properties"></xref>):<list style="symbols">
<t>Random-Access property is set to Random Acces;</t>
<t>Content Modifications set to unmutable;</t>
<t>Retetion set Unlimited or Time-Limited.</t>
</list>Playing on-demand media follows the general usage as
described in <xref target="sec_PLAY_general"></xref>.</t>
<t></t>
</section>
<section title="Playing Dynamic On-Demand Media">
<t>Dynamic on-demand media is indicated by the content of the
Media-Properties header in the SETUP response by (see also <xref
target="sec_Media-Properties"></xref>):<list style="symbols">
<t>Random-Access set to Random Access;</t>
<t>Content Modifications set to dynamic;</t>
<t>Retetion set unlimited or Time-Limited.</t>
</list></t>
<t>Playing on-demand media follows the general usage as described in
<xref target="sec_PLAY_general"></xref> as long as the media has not
been changed.</t>
<t>There are ways for the client to get informed about changed of
media resources in play state, if the resource was changed. The
client will receive a PLAY_NOTIFY request with Notify-Reason header
set to media-properties-update (see <xref
target="sec_Media-Properties-Update-Reason"></xref>. The client can
use the value of the Media-Range to decide further actions, if the
Media-Range header is present in the PLAY_NOTIFY request. The second
way is that the client issues a GET_PARAMETER request without a body
but including a Media-Range header. The 200 OK response SHALL
include the current Media-Range header (see <xref
target="sec_Media-Range"></xref>).</t>
</section>
<section title="Playing Live Media">
<t>Live media is indicated by the content of the Media-Properties
header in the SETUP response by (see also <xref
target="sec_Media-Properties"></xref>):<list style="symbols">
<t>Random-Access set to no-seeking;</t>
<t>Content Modifications set to Time-Progressing;</t>
<t>Retetion with Time-Duration set to 0.0.</t>
</list></t>
<t>For live media, the SETUP response 200 OK SHALL include the
Media-Range header (see <xref target="sec_Media-Range"></xref>).</t>
<t>A client MAY send PLAY requests without the Range header, if the
request include the Range header it SHALL use a symbolic value
representing "now". For NPT that range specification is "npt=now-".
The server SHALL include the Range header in the response and it
MUST indicate a explict time value and not a symbolic value. In
other words npt=now- is not a valid to use in the respone. Instead
the time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The
UTC clock format SHOULD only be used if client has shown support for
it.</t>
</section>
<section title="Playing Live with Recording">
<t>Certain media server may offer recording services of live
sessions to their clients. This recording would normally be from the
begining of the media session. Clients can randomly access the media
between now and the begining of the media session. This live media
with recording is indicated by the content of the Media-Properties
header in the SETUP response by (see also <xref
target="sec_Media-Properties"></xref>):<list style="symbols">
<t>Random-Access set to random-access;</t>
<t>Content Modifications set to Time-Progressing;</t>
<t>Retetion set to Time-limited or Unlimited</t>
</list></t>
<t>The SETUP response 200 OK SHALL include the Media-Range header
(see <xref target="sec_Media-Range"></xref>) for this type of media.
For live media with recording the Range header indicates the current
playback time in the media and the Media Range indicates the
currently available media window around the current time. This
window can cover recorded content in the past (seen from current
time in the media) or recorded content in the future (seen from
current time in the media). The server adjusts the play point to the
requested border of the window, if the client requests a play point
that is located outside the recording windows, e.g., if requested to
far in the past, the server selects the oldest range in the
recording. The considerations in <xref
target="sec_ScaleChange"></xref> apply, if a client requests
playback at <xref target="sec_Scale">Scale</xref> values other than
1.0 (Normal playback rate) while playing live media with
recording.</t>
</section>
<section title="Playing Live with Time-Shift">
<t>Certain media server may offer time-shift services to their
clients. This time shift records a fixed interval in the past, i.e.,
a sliding window recording mechanism, but not past this interval.
Clients can randomly access the media between now and the interval.
This live media with recording is indicated by the content of the
Media-Properties header in the SETUP response by (see also <xref
target="sec_Media-Properties"></xref>):<list style="symbols">
<t>Random-Access set to random-access;</t>
<t>Content Modifications set to Time-Progressing;</t>
<t>Retetion set to Time-Duration and a value indicating the
recording interval (>0).</t>
</list></t>
<t>The SETUP response 200 OK SHALL include the Media-Range header
(see <xref target="sec_Media-Range"></xref>) for this type of media.
For live media with recording the Range header indicates the current
time in the media and the Media Range indicates a window around the
current time. This window can cover recorded content in the past
(seen from current time in the media) or recorded content in the
future (seen from current time in the media). The server adjusts the
play point to the requested border of the window, if the client
requests a play point that is located outside the recording windows,
e.g., if requested to far in the past, the server selects the oldest
range in the recording. The considerations in <xref
target="sec_ScaleChange"></xref> apply, if a client requests
playback at <xref target="sec_Scale">Scale</xref> values other than
1.0 (Normal playback rate) while playing live media with
time-shift.</t>
</section>
</section>
<section anchor="sec_PLAY_NOTIFY" title="PLAY_NOTIFY">
<t>The PLAY_NOTIFY method is issued by a server to inform a client
about an ansynchronous event for a session in play state. The Session
header MUST be presented in a PLAY_NOTIFY request and indicates the
scope of the request. Sending of PLAY_NOTIFY requests requires a
persistent connection between server and client, otherwise there is no
way for the server to send this request method to the client.</t>
<t>PLAY_NOTIFY requests have an end-to-end (i.e. server to client)
scope, as they carry the Session header, and apply only to the given
session. The client SHOULD immediately return a response to the
server.</t>
<t>PLAY_NOTIFY requests MAY be used with a message body, depending on
the value of the Notify-Reason header. It is described in the
particular section for each Notify-Reason if a message body is used.
However, currently there is no Notify-Reason that allows using a
message body. There is the need to obey some limitations, when adding
new Notify-Reasons that intend to use a message body: The server can
send any type of message body, but it is not ensured that the client
can understand the received message body. This is related to DESCRIBE
(see<xref target="sec_DESCRIBE"> </xref> ), but there the client can
state its acceptable message bodies by using the Accept header. In
case of PLAY_NOTIFY, the server does not know which message bodies are
understood by the client.</t>
<t>The Notify-Reason header (see <xref
target="sec_Notify-Reason"></xref>) specifies the reason why the
server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future. In case the client does not
understand the reason for the notification it SHALL respond with an
<xref target="sec_error465">465 (Notification Reason Unknown)</xref>
error code. Servers can send PLAY_NOTIFY with these types:</t>
<t><list style="symbols">
<t>end-of-stream (see <xref
target="sec_end_of_stream"></xref>);</t>
<t>media-properties-update (see <xref
target="sec_Media-Properties-Update-Reason"></xref>);</t>
<t>and scale-change (see <xref
target="sec_ScaleChange"></xref>).</t>
</list></t>
<section anchor="sec_end_of_stream" title="End-of-Stream">
<t>A PLAY_NOTIFY request with Notify-Reason header set to
end-of-stream indicates the end of the media streams has been
reached or will be in the near future for the given session
aggregate. The request SHALL NOT be issued unless the server is in
the playing state. The end of the media stream delivery notification
may be for either succesful completion of the PLAY request currently
being served or indicate some error resulting in failure to complete
the request. The <xref target="sec_Request-Status">Request-Status
header</xref> SHALL be included to indicate which request the
notification is for and its completion status. The <xref
target="sec_status-code">message response status codes</xref> are
used to indicate how the PLAY request concluded. In case a
PLAY_NOTIFY was issues prior to the actual completion and some error
occured resulting in that the previosuly sent was in error a new
Notification MUST be sent including the correct status for the
completion and all additional information.</t>
<t>PLAY_NOTIFY requests with Notify-Reason header set to
end-of-stream MUST include a Range header. The Range header
indicates the point in the stream or streams where delivery was/are
ending with the timescale that has been used by the client in the
PLAY request being fulfilled. For normal play time it is not
alllowed to use "now" as server do know the real ending time of the
media stream and now carries no information to determine what
has/will be delivered. When 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 beyond the current time in the media
being received by the client, e.g., npt=-15, if npt is currently at
14.2 seconds.</t>
<t>If RTP is used as media transport, a RTP-Info header MUST be
included, and the RTP-Info header MUST indicate the last sequence
number in the seq parameter.</t>
<t>A PLAY_NOTIFY request with Notify-Reason header set to
end-of-stream MUST NOT carry a message body.</t>
<t>This example request notifies the client about a future
end-of-stream event:</t>
<t><figure>
<artwork><![CDATA[ S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: end-of-stream
Request-Status: cseq=853 status=200 reason="OK"
Range: npt=-145
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
Session: uZ3ci0K+Ld-M
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2]]></artwork>
</figure></t>
</section>
<section anchor="sec_Media-Properties-Update-Reason"
title="Media-Properties-Update">
<t>A PLAY_NOTIFY request with Notify-Reason header set to
media-properties-update indicates an update of the media properties
for the given session (see <xref
target="sec_Media-Properties"></xref>) and/or the available media
range that can be played as indicated by <xref
target="sec_Media-Range">Media-Range</xref>. PLAY_NOTIFY requests
with Notify-Reason header set to media-properties-update MUST
include a Media-Properties and Date header and SHOULD include a
Media-Range header.</t>
<t>This notification SHALL be sent for media that are
time-progressing every time a event happens that changes the basis
for making estimations on how the media range progress. In addition
it is RECOMMENDED that the server sends these notification every 5
minutes for time-progressing content to ensure the long term
stability of the client estimation and allowing for clock skew
detection by the client. Requests for the just mentioned reasons
SHALL include Media-Range header to provide current Media duration
and the Range header to indicate the current playing point and any
remaining parts of the requsted range.</t>
<t>A PLAY_NOTIFY request with Notify-Reason header set to
media-properties-update MUST NOT carry a message body.</t>
<t><figure>
<artwork><![CDATA[ S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854
Notify-Reason: media-properties-update
Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394
Range: npt=1:15:49.873-
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2]]></artwork>
</figure></t>
</section>
<section anchor="sec_ScaleChange" title="Scale-Change">
<t>When a client request playback at <xref
target="sec_Scale">Scale</xref> values other than 1.0 (Normal
playback rate) then the server may be forced to changed the rate.
For time progressing media with some retention, i.e. the server
stores already sent content, a client requesting to play with Scale
values larger than 1 may catch up with front end of the media. The
server will be unable to continue provide content at Scale larger
than 1 as content only made available by the server at Scale=1.
Another case is when Scale < 1 and the media retention is
time_duration limited. In this case the playback point can reach the
the oldest media unit available, and further playback at this scale
becomes impossible as there will be no media available. To avoid
having the client loose any media, the scale will need to be
adjusted to the same rate which the media is removed from the
storage buffer, commonly scale=1.0.</t>
<t>To minimize impact on playback in any of the above cases the
server SHALL modify the playback properties and set Scale to a
supportable value (commonly 1.0) and continue delivery the media.
When doing this modification it MUST send a PLAY_NOTIFY message with
the Notify-Reason header set to "Scale-Change". The request SHALL
contain a Range header with the media time where the change took
effect, a Scale header with the new value in use, Session header
with the ID for the session it applies to and a Date header with the
server wall clock time of the change. For time progressing content
also the Media-Range and the Media-Properties at this point in time
SHALL be included.</t>
<t>For media streams being delivered using RTP also a RTP-Info
header SHALL be included. It MUST contain the rtptime parameter with
a value corresponding to the point of change in that media and
optionally the sequence number.</t>
<t>A PLAY_NOTIFY request with Notify-Reason header set to
"Scale-Change" MUST NOT carry a message body.</t>
<t><figure>
<artwork><![CDATA[ S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854
Notify-Reason: scale-change
Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394
Range: npt=1:37:21.394-
Scale: 1
RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:rtptime=2345962545
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2]]></artwork>
</figure></t>
</section>
</section>
<section anchor="sec_PAUSE" title="PAUSE">
<t>The PAUSE request causes the stream delivery to immediately be
interrupted (halted). A PAUSE request MUST be done either with the
aggregated control URI for aggregated sessions, resulting in all media
being halted, or the media URI for non-aggregated sessions. Any
attempt to do muting of a single media with an PAUSE request in an
aggregated session SHALL be responded with error 460 (Only Aggregate
Operation Allowed). After resuming playback, synchronization of the
tracks MUST be maintained. Any server resources are kept, though
servers MAY close the session and free resources after being paused
for the duration specified with the timeout parameter of the Session
header in the SETUP message.</t>
<t>Example: <figure>
<artwork><![CDATA[
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: 12345678]]></artwork>
</figure><figure>
<artwork><![CDATA[ User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-]]></artwork>
</figure></t>
<t>The PAUSE request causes stream delivery to be interrupted
immediately on receipt of the message and the pause point is set to
the current point in the presentation. That pause point in the media
stream needs to be maintained. A subsequent PLAY request without Range
header SHALL resume from the pause point and play until media end.</t>
<t>The pause point after any PAUSE request SHALL be returned to the
client by adding a Range header with what remains unplayed of the PLAY
request's ranges, i.e. including all the remaining ranges part of
multiple range specification. For media with random access properties
If one desires to resume playing a ranged request, one simply includes
the Range header from the PAUSE response. Any play-request including
symbolic values, such as the NPT timescale's "now" MUST be resolved
into the actual stream position where the pause point is. For example
a Play request with a range specification of "npt=now-" will need to
be responded with an explicit value such as "npt=157.321-". For media
that is time-progressing and has retention duration=0 the follow-up
PLAY request to start media delivery again, will need to use
"npt=now-" and not the answer in the pause-respone. <figure>
<artwork><![CDATA[ C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: 12345678
Range: npt=10-30
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0
Range: npt=10-30
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678
After 11 seconds, i.e. at 21 seconds into the presentation:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0
Range: npt=21-30
Session: 12345678]]></artwork>
</figure></t>
<t>If a client issues a PAUSE request and the server acknowledges and
enters the READY state, the proper server response, if the player
issues another PAUSE, is still 200 OK. The 200 OK response MUST
include the Range header with the current pause point. See examples
below: <figure>
<artwork><![CDATA[
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Session: 12345678
Date: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36]]></artwork>
</figure></t>
</section>
<section anchor="sec_TEARDOWN" title="TEARDOWN">
<t>The TEARDOWN client to server request stops the stream delivery for
the given URI, freeing the resources associated with it. A TEARDOWN
request MAY be performed on either an aggregated or a media control
URI. However some restrictions apply depending on the current state.
The TEARDOWN request SHALL contain a Session header indicating what
session the request applies to.</t>
<t>A TEARDOWN using the aggregated control URI or the media URI in a
session under non-aggregated control (single media session) MAY be
done in any state (Ready, and Play). A successful request SHALL result
in that media delivery is immediately halted and the session state is
destroyed. This SHALL be indicated through the lack of a Session
header in the response.</t>
<t>A TEARDOWN using a media URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media
stream and associated resources from the session. This may result in
that a session returns to non-aggregated control, due to that it only
contains a single media after the requests completion. A session that
will exist after the processing of the TEARDOWN request SHALL in the
response to that TEARDOWN request contain a Session header. Thus the
presence of the Session header indicates to the receiver of the
response if the session is still existing or has been removed.</t>
<t>Example: <figure>
<artwork><![CDATA[
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892
Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 892
Server: PhonyServer 1.0]]></artwork>
</figure></t>
</section>
<section anchor="sec_GET_PARAMETER" title="GET_PARAMETER">
<t>The GET_PARAMETER request retrieves the value of any specified
parameter or parameters for a presentation or stream specified in the
URI. If the Session header is present in a request, the value of a
parameter MUST be retrieved in the specified session context. There
exist two ways of specifying the parameters to retrive. The first is
by including headers that has been defined such that you can use them
for this purpose. Header for this purpose should allow empty, or
stripped value parts to avoid having to specify bogus data when
indicating the desire to retrive a value. The succesful completion of
the request should also be evident from any filled out values in the
response. The <xref target="sec_Media-Range">Media-Range header</xref>
is one such header. The other is to specify a body (entity) that lists
the parameter(s) that are desirable to retrieve. The <xref
target="sec_Content-Type">Content-Type header</xref> is used to
specify which format the entity has.</t>
<t>The method MAY also be used without a body (entity) or any header
that request parameters for keep-alive purpose. Any request that is
successful, i.e., a 200 OK response is received, then the keep-alive
timer has been updated. Any non-required header present in such a
request may or may not been processed. Normaly the presence of filled
out values in the header will be indication that the header has been
processed. However, for cases when this is difficult to determine, it
is recommended to use a feature-tag and the Require header. Due to
this reason it is usually easier if any parameters to be retrieved are
sent in the body, rather than using any header.</t>
<t>Parameters specified within the body of the message must all be
understood by the request receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) SHALL be sent
including a body listing these parameters that wasn't understood. If
all parameters are understood their value is filled in and returned in
the response message body.</t>
<t>Example: <figure>
<artwork><![CDATA[
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 26
User-Agent: PhonyClient/1.2
packets_received
jitter
C->S: RTSP/2.0 200 OK
CSeq: 431
Content-Length: 38
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="sec_SET_PARAMETER" title="SET_PARAMETER">
<t>This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The
method MAY also be used without a body (entity). It is the RECOMMENDED
method to use in request sent for the sole purpose of updating the
keep-alive timer. If this request is successful, i.e. a 200 OK
response is received, then the keep-alive timer has been updated. Any
non-required header present in such a request may or may not been
processed. To allow a client to determine if any such header has been
processed, it is necessary to use a feature tag and the Require
header. Due to this reason it is RECOMMENDED that any parameters are
sent in the body, rather than using any header.</t>
<t>A request is RECOMMENDED to only contain a single parameter to
allow the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the request
does not understand or cannot locate a parameter, error 451 (Parameter
Not Understood) SHALL be used. In the case a parameter is not allowed
to change, the error code is 458 (Parameter Is Read-Only). The
response body SHALL contain only the parameters that have errors.
Otherwise no body SHALL be returned.</t>
<t>Note: transport parameters for the media stream MUST only be set
with the SETUP command.</t>
<t><list style="hanging">
<t>Restricting setting transport parameters to SETUP is for the
benefit of firewalls.</t>
</list></t>
<t><list style="hanging">
<t>The parameters are split in a fine-grained fashion so that
there can be more meaningful error indications. However, it may
make sense to allow the setting of several parameters if an atomic
setting is desirable. Imagine device control where the client does
not want the camera to pan unless it can also tilt to the right
angle at the same time.</t>
</list></t>
<t>Example: <figure>
<artwork><![CDATA[
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421
User-Agent: PhonyClient/1.2
Content-length: 20
Content-type: text/parameters
barparam: barstuff
S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam: barstuff]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="sec_REDIRECT" title="REDIRECT">
<t>The REDIRECT method is issued by a server to inform a client that
it required to connect to another server location to access the
resource indicated by the Request-URI. The presence of the Session
header in a REDIRECT request indicates the scope of the request, and
determines the specific semantics of the request.</t>
<t>A REDIRECT request with a Session header has end-to-end (i.e.
server to client) scope and applies only to the given session. Any
intervening proxies SHOULD NOT disconnect the control channel while
there are other remaining end-to-end sessions. The OPTIONAL Location
header, if included in such a request, SHALL contain a complete
absolute URI pointing to the resource to which the client SHOULD
reconnect. Specifically, the Location SHALL NOT contain just the host
and port. A client may receive a REDIRECT request with a Session
header, if and only if, an end-to-end session has been
established.</t>
<t>A client may receive a REDIRECT request without a Session header at
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.
the RTSP agent in direct communication with the server) and applies,
as well, to the control connection between the next-hop RTSP agent and
the server. A REDIRECT request without a Session header indicates that
all sessions and pending requests being managed via the control
connection MUST be redirected. The OPTIONAL Location header, if
included in such a request, SHOULD contain an absolute URI with only
the host address and the OPTIONAL port number of the server to which
the RTSP agent SHOULD reconnect. Any intervening proxies SHOULD do all
of the following in the order listed: <list hangIndent="3"
style="numbers">
<t>respond to the REDIRECT request</t>
<t>disconnect the control channel from the requesting server</t>
<t>connect to the server at the given host address</t>
<t>pass the REDIRECT request to each applicable client (typically
those clients with an active session or an unanswered request)</t>
</list></t>
<t><list style="hanging">
<t>Note: The proxy is responsible for accepting REDIRECT responses
from its clients; these responses MUST NOT be passed on to either
the original server or the redirected server.</t>
</list></t>
<t>The lack of a Location header in any REDIRECT request is indicative
of the server no longer being able to fulfill the current request and
having no alternatives for the client to continue with its normal
operation. It is akin to a server initiated TEARDOWN that applies both
to sessions as well as the general connection associated with that
client.</t>
<t>When the Range header is not included in a REDIRECT request, the
client SHOULD perform the redirection immediately and return a
response to the server. The server can consider the session as
terminated and can free any associated state after it receives the
successful (2xx) response. The server MAY close the signalling
connection upon receiving the response and the client SHOULD close the
signalling connection after sending the 2xx response. The exception to
this is when the client has several sessions on the server being
managed by the given signalling connection. In this case, the client
SHOULD close the connection when it has received and responded to
REDIRECT requests for all the sessions managed by the signalling
connection.</t>
<t>If the OPTIONAL Range header is included in a REDIRECT request, it
indicates when the redirection takes effect. The range value MUST be
an open ended single value, e.g. npt=59-, indicating the play out time
when redirection SHALL occur. Alternatively, a range with a time=
parameter indicates the wall clock time by when the redirection MUST
take place. When the time= parameter is present in the range, any
range value MUST be ignored even though it MUST be syntactically
correct. To allow a client to determine that redirect time without
being time synchronized with the server, the server SHALL include a
Date header in the request. When the indicated redirect point is
reached, a client MUST issue a TEARDOWN request and SHOULD close the
signalling connection after receiving a 2xx response. The normal
connection considerations apply for the server.</t>
<t><list style="hanging">
<t>The differentiation of REDIRECT requests with and without range
headers is to allow for clear and explicit state handling. As the
state in the server needs to be kept until the point of
redirection, the handling becomes more clear if the client is
required to TEARDOWN the session at the redirect point.</t>
</list></t>
<t>If the REDIRECT request times out following the rules in <xref
target="sec_connection-timeout"></xref> the server MAY terminate the
session or transport connection that would be redirected by the
request. This is a safeguard against misbehaving clients that refuses
to respond to a REDIRECT request. That should not provide any
benefit.</t>
<t>After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the
Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource URI,
a client SHOULD issue a DESCRIBE request for the URI.</t>
<t><list style="hanging">
<t>Note: The media resource indicated by the Location header can
be identical, slightly different or totally different. This is the
reason why a new DESCRIBE request SHOULD be issued.</t>
</list></t>
<t>If the Location header contains only a host address, the client MAY
assume that the media on the new server is identical to the media on
the old server, i.e. all media configuration information from the old
session is still valid except for the host address. However the usage
of conditional SETUP using ETag identifiers are RECOMMENDED to verify
the assumption.</t>
<t>This example request redirects traffic for this session to the new
server at the given absolute time: <figure>
<artwork><![CDATA[
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732
Location: rtsp://s2.example.com:8001
Range: npt=0- ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M
C->S: RTSP/2.0 200 OK
CSeq: 732
User-Agent: PhonyClient/1.2]]></artwork>
</figure></t>
</section>
</section>
<section anchor="sec_binary" title="Embedded (Interleaved) Binary Data">
<t>In order to fulfill certain requirements on the network side, e.g. in
conjunction with network address translators that block RTP traffic over
UDP, it may be necessary to interleave RTSP messages and media stream
data. This interleaving should generally be avoided unless necessary
since it complicates client and server operation and imposes additional
overhead. Also head of line blocking may cause problems. Interleaved
binary data SHOULD only be used if RTSP is carried over TCP.</t>
<t>Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (24 decimal), followed by a one-byte channel identifier, followed
by the length of the encapsulated binary data as a binary, two-byte
integer in network byte order. The stream data follows immediately
afterwards, without a CRLF, but including the upper-layer protocol
headers. Each $ block SHALL contain exactly one upper-layer protocol
data unit, e.g., one RTP packet. <figure>
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 24 | Channel ID | Length in bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>The channel identifier is defined in the Transport header with the
interleaved parameter (<xref target="sec_Transport"></xref>).</t>
<t>When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is
indicated by including a range containing a second channel in the
interleaved parameter of the Transport header, see <xref
target="sec_Transport"></xref>. If RTCP is used, packets SHALL be sent
on the first available channel higher than the RTP channel. The channels
are bi-directional and therefore RTCP traffic are sent on the second
channel in both directions.</t>
<t><list style="hanging">
<t>RTCP is sometime needed for synchronization when two or more
streams are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP control
connection when required by the network configuration and transfer
them onto UDP when possible.</t>
</list></t>
<t><figure>
<artwork><![CDATA[
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 2
Date: Thu, 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678
Accept-Ranges: NPT
C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3
Session: 12345678
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: 12345678
Date: Thu, 05 Jun 1997 18:59:15 GMT
RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234
Range: npt=0-56.8
S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet}]]></artwork>
</figure></t>
</section>
<section anchor="sec_status" title="Status Code Definitions">
<t>Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See <xref
target="tab_status"></xref> for a listing of which status codes may be
returned by which requests. All error messages, 4xx and 5xx MAY return a
body containing further information about the error.</t>
<section title="Success 1xx">
<section title="100 Continue">
<t>See, [H10.1.1].</t>
</section>
</section>
<section title="Success 2xx">
<section title="200 OK">
<t>See, [H10.2.1].</t>
</section>
</section>
<section anchor="sec_status-redirect" title="Redirection 3xx">
<t>The notation "3rr" indicates response codes from 300 to 399
inclusive which are meant for redirection. The response code 304 is
excluded from this set, as it is not used for redirection.</t>
<t>See [H10.3] for definition of status code 300 to 305. However
comments are given for some to how they apply to RTSP.</t>
<t>Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the
client. Mechanisms to determine topological proximity are beyond the
scope of this specification.</t>
<t>A 3rr code MAY be used to respond to any request. It is RECOMMENDED
that they are used if necessary before a session is established, i.e.
in response to DESCRIBE or SETUP. However in cases where a server is
not able to send a REDIRECT request to the client, the server MAY need
to resort to using 3rr responses to inform a client with a established
session about the need for redirecting the session. If an 3rr response
is received for an request in relation to a established session, the
client SHOULD send a TEARDOWN request for the session, and MAY
reestablish the session using the resource indicated by the
Location.</t>
<t>If the the Location header is used in a response it SHALL contain
an absolute URI pointing out the media resource the client is
redirected to, the URI SHALL NOT only contain the host name.</t>
<section title="300 Multiple Choices">
<t>See [H10.3.1].</t>
</section>
<section title="301 Moved Permanently">
<t>The request resource are moved permanently and resides now at the
URI given by the location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a
message-body. The Location header MUST be included in the
response.</t>
</section>
<section title="302 Found">
<t>The requested resource resides temporarily at the URI given by
the Location header. The Location header MUST be included in the
response. This response is intended to be used for many types of
temporary redirects; e.g., load balancing. It is RECOMMENDED that
the server set the reason phrase to something more meaningful than
"Found" in these cases. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a
message-body.</t>
<t>This example shows a client being redirected to a different
server: <figure>
<artwork><![CDATA[
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 302 Try Other Server
CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo]]></artwork>
</figure></t>
</section>
<section title="303 See Other">
<t>This status code SHALL NOT be used in RTSP. However, it was
allowed to use in RTSP 1.0 (RFC 2326).</t>
</section>
<section title="304 Not Modified">
<t>If the client has performed a conditional DESCRIBE or SETUP (see
<xref target="sec_If-Modified-Since"></xref>) and the requested
resource has not been modified, the server SHOULD send a 304
response. This response MUST NOT contain a message-body.</t>
<t>The response MUST include the following header fields: <list
hangIndent="3" style="symbols">
<t>Date</t>
<t>ETag and/or Content-Location, if the header(s) would have
been sent in a 200 response to the same request.</t>
<t>Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant.</t>
</list></t>
<t>This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged (only the session description) and a 304
response to SETUP does NOT imply that the resource description is
unchanged. The ETag and If-Match headers may be used to link the
DESCRIBE and SETUP in this manner.</t>
</section>
<section title="305 Use Proxy">
<t>See [H10.3.6].</t>
</section>
</section>
<section title="Client Error 4xx">
<section title="400 Bad Request">
<t>The request could not be understood by the server due to
malformed syntax. The client SHOULD NOT repeat the request without
modifications [H10.4.1]. If the request does not have a CSeq header,
the server MUST NOT include a CSeq in the response.</t>
</section>
<section title="405 Method Not Allowed">
<t>The method specified in the request is not allowed for the
resource identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the requested
resource. This status code is also to be used if a request attempts
to use a method not indicated during SETUP.</t>
</section>
<section title="451 Parameter Not Understood">
<t>The recipient of the request does not support one or more
parameters contained in the request. When returning this error
message the sender SHOULD return a entity body containing the
offending parameter(s).</t>
</section>
<section title="452 reserved">
<t>This error code was removed from RFC 2326 <xref
target="RFC2326"></xref> and is obsolete.</t>
</section>
<section title="453 Not Enough Bandwidth">
<t>The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation
failure.</t>
</section>
<section title="454 Session Not Found">
<t>The RTSP session identifier in the Session header is missing,
invalid, or has timed out.</t>
</section>
<section title="455 Method Not Valid in This State">
<t>The client or server cannot process this request in its current
state. The response SHALL contain an Allow header to make error
recovery possible.</t>
</section>
<section title="456 Header Field Not Valid for Resource">
<t>The server could not act on a required request header. For
example, if PLAY contains the Range header field but the stream does
not allow seeking. This error message may also be used for
specifying when the time format in Range is impossible for the
resource. In that case the Accept-Ranges header SHALL be returned to
inform the client of which format(s) that are allowed.</t>
</section>
<section title="457 Invalid Range">
<t>The Range value given is out of bounds, e.g., beyond the end of
the presentation.</t>
</section>
<section title="458 Parameter Is Read-Only">
<t>The parameter to be set by SET_PARAMETER can be read but not
modified. When returning this error message the sender SHOULD return
a entity body containing the offending parameter(s).</t>
</section>
<section anchor="sec_error459"
title="459 Aggregate Operation Not Allowed">
<t>The requested method may not be applied on the URI in question
since it is an aggregate (presentation) URI. The method may be
applied on a media URI.</t>
</section>
<section anchor="sec_error460"
title="460 Only Aggregate Operation Allowed">
<t>The requested method may not be applied on the URI in question
since it is not an aggregate control (presentation) URI. The method
may be applied on the aggregate control URI.</t>
</section>
<section title="461 Unsupported Transport">
<t>The Transport field did not contain a supported transport
specification.</t>
</section>
<section title="462 Destination Unreachable">
<t>The data transmission channel could not be established because
the client address could not be reached. This error will most likely
be the result of a client attempt to place an invalid dest_addr
parameter in the Transport field.</t>
</section>
<section title="463 Destination Prohibited">
<t>The data transmission channel was not established because the
server prohibited access to the client address. This error is most
likely the result of a client attempt to redirect media traffic to
another destination with a dest_addr parameter in the Transport
header.</t>
</section>
<section anchor="sec_error464"
title="464 Data Transport Not Ready Yet">
<t>The data transmission channel to the media destination is not yet
ready for carrying data. However the responding entity still expects
that the data transmission channel will be established at this point
in time. Note however that this may result in a permanent failure
like 462 "Destination Unreachable".</t>
<t>An example when this error may occur is in the case a client
sends a PLAY request to a server prior to ensuring that the TCP
connections negotiated for carrying media data was successful
established (In violation of this specification). The server would
use this error code to indicate that the requested action could not
be performed due to the failure of completing the connection
establishment.</t>
</section>
<section anchor="sec_error465" title="465 Notification Reason Unknown">
<t>The client has received a <xref
target="sec_PLAY_NOTIFY">PLAY_NOTIFY</xref> with a <xref
target="sec_Notify-Reason">Notify-Reason header</xref> indicates a
reson that are unknown to the client.</t>
</section>
<section title="470 Connection Authorization Required">
<t>The secured connection attempt need user or client authorization
before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header.</t>
</section>
<section title="471 Connection Credentials not accepted">
<t>When performing a secure connection over multiple connections, a
intermediary has refused to connect to the next hop and carry out
the request due to unacceptable credentials for the used policy.</t>
</section>
<section title="472 Failure to establish secure connection">
<t>A proxy fails to establish a secure connection to the next hop
RTSP agent. This is primarily caused by a fatal failure at the TLS
handshake, for example due to server not accepting any cipher
suits.</t>
</section>
</section>
<section title="Server Error 5xx">
<section title="551 Option not supported">
<t>A feature-tag given in the Require or the Proxy-Require fields
was not supported. The Unsupported header SHALL be returned stating
the feature for which there is no support.</t>
</section>
</section>
</section>
<section anchor="sec_headers" title="Header Field Definitions">
<t><texttable anchor="tab_methods2"
title="Overview of RTSP methods, their direction, and what objects (P: presentation, S: stream) they operate on. Body notes if a method is allowed to carry body and in which direction, R = Request, r=response. Note: It is allowed for all error messages 4xx and 5xx to have a body">
<preamble />
<ttcol align="left">method</ttcol>
<ttcol align="left">direction</ttcol>
<ttcol align="left">object</ttcol>
<ttcol align="left">acronym</ttcol>
<ttcol align="left">Body</ttcol>
<c>DESCRIBE</c>
<c>C -> S</c>
<c>P,S</c>
<c>DES</c>
<c>r</c>
<c>GET_PARAMETER</c>
<c>C -> S, S -> C</c>
<c>P,S</c>
<c>GPR</c>
<c>R,r</c>
<c>OPTIONS</c>
<c>C -> S</c>
<c>P,S</c>
<c>OPT</c>
<c />
<c />
<c>S -> C</c>
<c />
<c />
<c />
<c>PAUSE</c>
<c>C -> S</c>
<c>P,S</c>
<c>PSE</c>
<c />
<c>PLAY</c>
<c>C -> S</c>
<c>P,S</c>
<c>PLY</c>
<c />
<c>PLAY_NOTIFY</c>
<c>S -> C</c>
<c>P,S</c>
<c>PNY</c>
<c>R</c>
<c>REDIRECT</c>
<c>S -> C</c>
<c>P,S</c>
<c>RDR</c>
<c />
<c>SETUP</c>
<c>C -> S</c>
<c>S</c>
<c>STP</c>
<c />
<c>SET_PARAMETER</c>
<c>C -> S, S -> C</c>
<c>P,S</c>
<c>SPR</c>
<c>R,r</c>
<c>TEARDOWN</c>
<c>C -> S</c>
<c>P,S</c>
<c>TRD</c>
<c />
</texttable></t>
<t>The general syntax for header fields is covered in <xref
target="sec_message-headers"></xref>. This section lists the full set of
header fields along with notes on meaning, and usage. The syntax
definition for header fields are present in <xref
target="sec_syntax-prot-header"></xref>. Throughout this section, we use
[HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification RFC
2616 <xref target="RFC2616"></xref>. Examples of each header field are
given.</t>
<t>Information about header fields in relation to methods and proxy
processing is summarized in <xref target="tab_headers1a"></xref>, <xref
target="tab_headers1b"></xref>, <xref target="tab_headers2a"></xref>,
and <xref target="tab_headers2b"></xref>.</t>
<t>The "where" column describes the request and response types in which
the header field can be used. Values in this column are: <list
hangIndent="6" style="hanging">
<t hangText="R:">header field may only appear in requests;</t>
<t hangText="r:">header field may only appear in responses;</t>
<t hangText="2xx, 4xx, etc.:">A numerical value or range indicates
response codes with which the header field can be used;</t>
<t hangText="c:">header field is copied from the request to the
response.</t>
</list></t>
<t>An empty entry in the "where" column indicates that the header field
may be present in both requests and responses.</t>
<t>The "proxy" column describes the operations a proxy may perform on a
header field. An empty proxy column indicates that the proxy SHALL NOT
do any changes to that header, all allowed operations are explicitly
stated: <list hangIndent="6" style="hanging">
<t hangText="a:">A proxy can add or concatenate the header field if
not present.</t>
<t hangText="m:">A proxy can modify an existing header field
value.</t>
<t hangText="d:">A proxy can delete a header field value.</t>
<t hangText="r:">A proxy needs to be able to read the header field,
and thus this header field cannot be encrypted.</t>
</list></t>
<t>The rest of the columns relate to the presence of a header field in a
method. The method names when abbreviated, are according to <xref
target="tab_methods2"></xref>: <list hangIndent="6" style="hanging">
<t hangText="c:">Conditional; requirements on the header field
depend on the context of the message.</t>
<t hangText="m:">The header field is mandatory.</t>
<t hangText="m*:">The header field SHOULD be sent, but
clients/servers need to be prepared to receive messages without that
header field.</t>
<t hangText="o:">The header field is optional.</t>
<t hangText="*:">The header field is SHALL be present if the message
body is not empty. See <xref target="sec_Content-Length"></xref>,
<xref target="sec_Content-Type"></xref> and <xref
target="sec_message-body"></xref> for details.</t>
<t hangText="-:">The header field is not applicable.</t>
</list></t>
<t>"Optional" means that a Client/Server MAY include the header field in
a request or response. The Client/Server behavior when receiving such
headers varies, for some it may ignore the header field, in other case
it is request to process the header. This is regulated by the method and
header descriptions. Example of such headers that require processing are
the Require and Proxy-Require header fields discussed in <xref
target="sec_Require"></xref> and <xref
target="sec_Proxy-Require"></xref>. A "mandatory" header field MUST be
present in a request, and MUST be understood by the Client/Server
receiving the request. A mandatory response header field MUST be present
in the response, and the header field MUST be understood by the
Client/Server processing the response. "Not applicable" means that the
header field MUST NOT be present in a request. If one is placed in a
request by mistake, it MUST be ignored by the Client/Server receiving
the request. Similarly, a header field labeled "not applicable" for a
response means that the Client/Server MUST NOT place the header field in
the response, and the Client/Server MUST ignore the header field in the
response.</t>
<t>An RTSP agent SHALL ignore extension headers that are not
understood.</t>
<t>The From and Location header fields contain an URI. If the URI
contains a comma, or semicolon, the URI MUST be enclosed in double
quotas ("). Any URI parameters are contained within these quotas. If the
URI is not enclosed in double quotas, any semicolon- delimited
parameters are header-parameters, not URI parameters.</t>
<t><texttable anchor="tab_headers1a"
title="Overview of RTSP header fields (A-L) related to methods DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.">
<preamble />
<ttcol align="left">Header</ttcol>
<ttcol align="left">Where</ttcol>
<ttcol align="left">Proxy</ttcol>
<ttcol align="left">DES</ttcol>
<ttcol align="left">OPT</ttcol>
<ttcol align="left">SETUP</ttcol>
<ttcol align="left">PLAY</ttcol>
<ttcol align="left">PAUSE</ttcol>
<ttcol align="left">TRD</ttcol>
<c>Accept</c>
<c>R</c>
<c />
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Accept-Credentials</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Accept-Encoding</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Accept-Language</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Accept-Ranges</c>
<c>R</c>
<c>r</c>
<c>-</c>
<c>-</c>
<c>m</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Accept-Ranges</c>
<c>r</c>
<c>r</c>
<c>-</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Accept-Ranges</c>
<c>456</c>
<c>r</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Allow</c>
<c>r</c>
<c>am</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Allow</c>
<c>405</c>
<c>am</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>Authorization</c>
<c>R</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Bandwidth</c>
<c>R</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Blocksize</c>
<c>R</c>
<c />
<c>o</c>
<c>-</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Cache-Control</c>
<c />
<c>r</c>
<c>o</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Connection</c>
<c />
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Connection-Credentials</c>
<c>470,407</c>
<c>ar</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Content-Base</c>
<c>r</c>
<c />
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Content-Base</c>
<c>4xx,5xx</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Content-Encoding</c>
<c>R</c>
<c>r</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Content-Encoding</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Content-Encoding</c>
<c>4xx,5xx</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Content-Language</c>
<c>R</c>
<c>r</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Content-Language</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Content-Language</c>
<c>4xx,5xx</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Content-Length</c>
<c>r</c>
<c>r</c>
<c>*</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Content-Length</c>
<c>4xx,5xx</c>
<c>r</c>
<c>*</c>
<c>*</c>
<c>*</c>
<c>*</c>
<c>*</c>
<c>*</c>
<c>Content-Location</c>
<c>r</c>
<c />
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Content-Location</c>
<c>4xx,5xx</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Content-Type</c>
<c>r</c>
<c />
<c>*</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Content-Type</c>
<c>4xx,5xx</c>
<c />
<c>*</c>
<c>*</c>
<c>*</c>
<c>*</c>
<c>*</c>
<c>*</c>
<c>CSeq</c>
<c>Rc</c>
<c>rm</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>Date</c>
<c />
<c>am</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>ETag</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Expires</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>From</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>If-Match</c>
<c>R</c>
<c>r</c>
<c>-</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>If-Modified-Since</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>If-None-Match</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Last-Modified</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Location</c>
<c>3rr</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
</texttable> <texttable anchor="tab_headers1b"
title="Overview of RTSP header fields (P-W) related to methods DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.">
<preamble />
<ttcol align="left">Header</ttcol>
<ttcol align="left">Where</ttcol>
<ttcol align="left">Proxy</ttcol>
<ttcol align="left">DES</ttcol>
<ttcol align="left">OPT</ttcol>
<ttcol align="left">SETUP</ttcol>
<ttcol align="left">PLAY</ttcol>
<ttcol align="left">PAUSE</ttcol>
<ttcol align="left">TRD</ttcol>
<c>Media- Properties</c>
<c />
<c />
<c>-</c>
<c>-</c>
<c>r</c>
<c>r</c>
<c>r</c>
<c>-</c>
<c>Media- Range</c>
<c />
<c />
<c>-</c>
<c>-</c>
<c>r</c>
<c>r</c>
<c>r</c>
<c>-</c>
<c>Pipelined- Requests</c>
<c />
<c>amdr</c>
<c>-</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Proxy- Authenticate</c>
<c>407</c>
<c>amr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>Proxy- Authorization</c>
<c>R</c>
<c>rd</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Proxy- Require</c>
<c>R</c>
<c>ar</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Proxy- Require</c>
<c>r</c>
<c>r</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>Proxy- Supported</c>
<c>R</c>
<c>amr</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>Proxy- Supported</c>
<c>r</c>
<c />
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>Public</c>
<c>r</c>
<c>admr</c>
<c>-</c>
<c>m</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Public</c>
<c>501</c>
<c>admr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>Range</c>
<c>R</c>
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Range</c>
<c>r</c>
<c />
<c>-</c>
<c>-</c>
<c>c</c>
<c>m</c>
<c>m</c>
<c>-</c>
<c>Referer</c>
<c>R</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Request- Status</c>
<c>R</c>
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Require</c>
<c>R</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Retry-After</c>
<c>3rr,503</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>RTP-Info</c>
<c>r</c>
<c />
<c>-</c>
<c>-</c>
<c>c</c>
<c>c</c>
<c>-</c>
<c>-</c>
<c>Scale</c>
<c />
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Seek-Style</c>
<c>R</c>
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Seek-Style</c>
<c>r</c>
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>m</c>
<c>-</c>
<c>-</c>
<c>Session</c>
<c>R</c>
<c>r</c>
<c>-</c>
<c>o</c>
<c>o</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>Session</c>
<c>r</c>
<c>r</c>
<c>-</c>
<c>c</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>o</c>
<c>Server</c>
<c>R</c>
<c>r</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Server</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Speed</c>
<c />
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Supported</c>
<c>R</c>
<c>amr</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Supported</c>
<c>r</c>
<c>amr</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>Timestamp</c>
<c>R</c>
<c>admr</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Timestamp</c>
<c>c</c>
<c>admr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>Transport</c>
<c />
<c>amr</c>
<c>-</c>
<c>-</c>
<c>m</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Unsupported</c>
<c>r</c>
<c />
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>User-Agent</c>
<c>R</c>
<c />
<c>m*</c>
<c>m*</c>
<c>m*</c>
<c>m*</c>
<c>m*</c>
<c>m*</c>
<c>Vary</c>
<c>r</c>
<c />
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>Via</c>
<c>R</c>
<c>amr</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>Via</c>
<c>c</c>
<c>dr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>WWW- Authenticate</c>
<c>401</c>
<c />
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
</texttable> <texttable anchor="tab_headers2a"
title="Overview of RTSP header fields (A-P) related to methods GETPARAMETER, SETPARAMETER, PLAY_NOTIFY, and REDIRECT.">
<preamble />
<ttcol align="left">Header</ttcol>
<ttcol align="left">Where</ttcol>
<ttcol align="left">Proxy</ttcol>
<ttcol align="left">GPR</ttcol>
<ttcol align="left">SPR</ttcol>
<ttcol align="left">RDR</ttcol>
<ttcol align="left">PNY</ttcol>
<c>Accept-Credentials</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Allow</c>
<c>405</c>
<c>amr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>-</c>
<c>Authorization</c>
<c>R</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Bandwidth</c>
<c>R</c>
<c />
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Blocksize</c>
<c>R</c>
<c />
<c>-</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Connection</c>
<c />
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Connection-Credentials</c>
<c>470,407</c>
<c>ar</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Content-Base</c>
<c>R</c>
<c />
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Content-Base</c>
<c>r</c>
<c />
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Content-Base</c>
<c>4xx,5xx</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Content-Encoding</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Content-Encoding</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Content-Encoding</c>
<c>4xx,5xx</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Content-Language</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Content-Language</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Content-Language</c>
<c>4xx,5xx</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Content-Length</c>
<c>R</c>
<c>r</c>
<c>*</c>
<c>*</c>
<c>-</c>
<c>-</c>
<c>Content-Length</c>
<c>r</c>
<c>r</c>
<c>*</c>
<c>*</c>
<c>-</c>
<c>-</c>
<c>Content-Length</c>
<c>4xx,5xx</c>
<c>r</c>
<c>*</c>
<c>*</c>
<c>*</c>
<c>-</c>
<c>Content-Location</c>
<c>R</c>
<c />
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Content-Location</c>
<c>r</c>
<c />
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Content-Location</c>
<c>4xx,5xx</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Content-Type</c>
<c>R</c>
<c />
<c>*</c>
<c>*</c>
<c>-</c>
<c>-</c>
<c>Content-Type</c>
<c>r</c>
<c />
<c>*</c>
<c>*</c>
<c>-</c>
<c>-</c>
<c>Content-Type</c>
<c>4xx</c>
<c />
<c>*</c>
<c>*</c>
<c>*</c>
<c>-</c>
<c>CSeq</c>
<c>R,c</c>
<c>mr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>Date</c>
<c>R</c>
<c>a</c>
<c>o</c>
<c>o</c>
<c>m</c>
<c>-</c>
<c>Date</c>
<c>r</c>
<c>am</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>From</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Last-Modified</c>
<c>R</c>
<c>r</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Last-Modified</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Location</c>
<c>3rr</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Location</c>
<c>R</c>
<c />
<c>-</c>
<c>-</c>
<c>m</c>
<c>-</c>
<c>Media-Properties</c>
<c />
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c />
<c>Media-Range</c>
<c>R</c>
<c />
<c>o</c>
<c>-</c>
<c>-</c>
<c>c</c>
<c>Media-Range</c>
<c>r</c>
<c />
<c>c</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Notify-Reason</c>
<c>R</c>
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>m</c>
<c>Pipelined-Requests</c>
<c />
<c>amdr</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Proxy-Authenticate</c>
<c>407</c>
<c>amr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>-</c>
<c>Proxy-Authorization</c>
<c>R</c>
<c>rd</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Proxy-Require</c>
<c>R</c>
<c>ar</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Proxy-Require</c>
<c>r</c>
<c>r</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>-</c>
<c>Proxy-Supported</c>
<c>R</c>
<c>amr</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>-</c>
<c>Proxy-Supported</c>
<c>r</c>
<c />
<c>c</c>
<c>c</c>
<c>c</c>
<c>-</c>
<c>Public</c>
<c>501</c>
<c>admr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>-</c>
</texttable> <texttable anchor="tab_headers2b"
title="Overview of RTSP header fields (R-W) related to methods GETPARAMETER, SETPARAMETER, PLAY_NOTIFY, and REDIRECT.">
<preamble />
<ttcol align="left">Header</ttcol>
<ttcol align="left">Where</ttcol>
<ttcol align="left">Proxy</ttcol>
<ttcol align="left">GPR</ttcol>
<ttcol align="left">SPR</ttcol>
<ttcol align="left">RDR</ttcol>
<ttcol align="left">PNY</ttcol>
<c>Range</c>
<c>R</c>
<c />
<c>-</c>
<c>-</c>
<c>o</c>
<c>m</c>
<c>Referer</c>
<c>R</c>
<c />
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Request-Status</c>
<c>R</c>
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>m</c>
<c>Require</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Retry-After</c>
<c>3rr,503</c>
<c />
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Scale</c>
<c />
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>c</c>
<c>Seek-Style</c>
<c />
<c />
<c>-</c>
<c>-</c>
<c>-</c>
<c>-</c>
<c>Session</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>m</c>
<c>Session</c>
<c>r</c>
<c>r</c>
<c>c</c>
<c>c</c>
<c>o</c>
<c>m</c>
<c>Server</c>
<c>R</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Server</c>
<c>r</c>
<c>r</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>-</c>
<c>Supported</c>
<c>R</c>
<c>adrm</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Supported</c>
<c>r</c>
<c>adrm</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>-</c>
<c>Timestamp</c>
<c>R</c>
<c>adrm</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Timestamp</c>
<c>c</c>
<c>adrm</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>-</c>
<c>Unsupported</c>
<c>r</c>
<c>arm</c>
<c>c</c>
<c>c</c>
<c>c</c>
<c>-</c>
<c>User-Agent</c>
<c>R</c>
<c>r</c>
<c>m*</c>
<c>m*</c>
<c>-</c>
<c>-</c>
<c>User-Agent</c>
<c>r</c>
<c>r</c>
<c>-</c>
<c>-</c>
<c>m*</c>
<c>-</c>
<c>Vary</c>
<c>r</c>
<c />
<c>c</c>
<c>c</c>
<c>-</c>
<c>-</c>
<c>Via</c>
<c>R</c>
<c>amr</c>
<c>o</c>
<c>o</c>
<c>o</c>
<c>-</c>
<c>Via</c>
<c>c</c>
<c>dr</c>
<c>m</c>
<c>m</c>
<c>m</c>
<c>-</c>
<c>WWW-Authenticate</c>
<c>401</c>
<c />
<c>m</c>
<c>m</c>
<c>m</c>
<c>-</c>
</texttable></t>
<section anchor="sec_Accept" title="Accept">
<t>The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the
response.</t>
<t>See [H14.1] for syntax.</t>
<t>Example of use: <figure>
<artwork><![CDATA[ Accept: application/example q=1.0, application/sdp
]]></artwork>
</figure></t>
</section>
<section anchor="sec_Accept-Credentials" title="Accept-Credentials">
<t>The Accept-Credentials header is a request header used to indicate
to any trusted intermediary how to handle further secured connections
to proxies or servers. See <xref
target="sec_security-framework"></xref> for the usage of this header.
It SHALL NOT be included in server to client requests.</t>
<t>In a request the header SHALL contain the method (User, Proxy, or
Any) for approving credentials selected by the requestor. The method
SHALL NOT be changed by any proxy, unless it is "proxy" when a proxy
MAY change it to "user" to take the role of user approving each
further hop. If the method is "User" the header contains zero or more
of credentials that the client accepts. The header may contain zero
credentials in the first RTSP request to a RTSP server when using the
"User" method. This as the client has not yet received any credentials
to accept. Each credential SHALL consist of one URI identifying the
proxy or server, the hash algorithm identifier, and the hash over that
entity's DER encoded certificate <xref target="RFC3280"></xref> in
<xref target="RFC4648">Base64</xref>. All RTSP clients and proxies
SHALL implement the SHA-256<xref target="FIPS-pub-180-2"></xref>
algorithm for computation of the hash of the DER encoded certificate.
The SHA-256 algorithm is identified by the token "sha-256".</t>
<t>The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented somewhere
else than here. Thus the definition of future algorithms for this
purpose is intended to be extremely limited. A feature tag can be used
to ensure that support for the replacement algorithm exist.</t>
<t>Example: <figure>
<artwork><![CDATA[ Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
]]></artwork>
</figure></t>
</section>
<section anchor="sec_Accept-Encoding" title="Accept-Encoding">
<t>See [H14.3].</t>
</section>
<section anchor="sec_Accept-Language" title="Accept-Language">
<t>See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media
content.</t>
</section>
<section anchor="sec_Accept-Ranges" title="Accept-Ranges">
<t>The Accept-Ranges request and response-header field allows
indication of the format supported in the Range header. The client
SHALL include the header in SETUP requests to indicate which formats
it support to receive in PLAY and PAUSE responses, and REDIRECT
requests. The server SHALL include the header in SETUP and 456 error
responses to indicate the formats supported for the resource indicated
by the request URI. <figure>
<artwork><![CDATA[ Accept-Ranges: NPT, SMPTE]]></artwork>
</figure></t>
<t>This header has the same syntax as [H14.5] and the syntax is
defined in <xref target="sec_syntax-prot-header"></xref>. However, new
range-units are defined.</t>
</section>
<section anchor="sec_Allow" title="Allow">
<t>The Allow entity-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition. The Allow header
MUST also be present in all OPTIONS responses where the content of the
header will not include exactly the same methods as listed in the
Public header.</t>
<t>The Allow SHALL also be included in SETUP and DESCRIBE responses,
if the methods allowed for the resource is different than the minimal
implementation set.</t>
<t>Example of use: <figure>
<artwork><![CDATA[ Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
]]></artwork>
</figure></t>
</section>
<section anchor="sec_Authorization" title="Authorization">
<t>See [H14.8].</t>
</section>
<section anchor="sec_Bandwidth" title="Bandwidth">
<t>The Bandwidth request-header field describes the estimated
bandwidth available to the client, expressed as a positive integer and
measured in bits per second. The bandwidth available to the client may
change during an RTSP session, e.g., due to mobility, congestion,
etc.</t>
<t>Example: <figure>
<artwork><![CDATA[ Bandwidth: 62360]]></artwork>
</figure></t>
</section>
<section anchor="sec_Blocksize" title="Blocksize">
<t>The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, UDP,
or RTP. The server is free to use a blocksize which is lower than the
one requested. The server MAY truncate this packet size to the closest
multiple of the minimum, media-specific block size, or override it
with the media-specific size if necessary. The block size MUST be a
positive decimal number, measured in octets. The server only returns
an error (4xx) if the value is syntactically invalid.</t>
</section>
<section anchor="sec_Cache-Control" title="Cache-Control">
<t>The Cache-Control general-header field is used to specify
directives that MUST be obeyed by all caching mechanisms along the
request/response chain.</t>
<t>Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a
cache-directive for a specific cache.</t>
<t>Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does not govern the caching of responses
as for HTTP, instead it applies to the media stream identified by the
SETUP request. The RTSP requests are generally not cacheable, for
further information see <xref target="sec_caching"></xref>. Below is
the description of the cache directives that can be included in the
Cache-Control header.</t>
<t><list hangIndent="6" style="hanging">
<t hangText="no-cache:">Indicates that the media stream MUST NOT
be cached anywhere. This allows an origin server to prevent
caching even by caches that have been configured to return stale
responses to client requests. Note, there is no security function
enforcing that the content can't be cached.</t>
<t hangText="public:">Indicates that the media stream is cacheable
by any cache.</t>
<t hangText="private:">Indicates that the media stream is intended
for a single user and MUST NOT be cached by a shared cache. A
private (non-shared) cache may cache the media streams.</t>
<t hangText="no-transform:">An intermediate cache (proxy) may find
it useful to convert the media type of a certain stream. A proxy
might, for example, convert between video formats to save cache
space or to reduce the amount of traffic on a slow link. Serious
operational problems may occur, however, when these
transformations have been applied to streams intended for certain
kinds of applications. For example, applications for medical
imaging, scientific data analysis and those using end-to-end
authentication all depend on receiving a stream that is
bit-for-bit identical to the original media stream. Therefore, if
a response includes the no-transform directive, an intermediate
cache or proxy MUST NOT change the encoding of the stream. Unlike
HTTP, RTSP does not provide for partial transformation at this
point, e.g., allowing translation into a different language.</t>
<t hangText="only-if-cached:">In some cases, such as times of
extremely poor network connectivity, a client may want a cache to
return only those media streams that it currently has stored, and
not to receive these from the origin server. To do this, the
client may include the only-if-cached directive in a request. If
it receives this directive, a cache SHOULD either respond using a
cached media stream that is consistent with the other constraints
of the request, or respond with a 504 (Gateway Timeout) status.
However, if a group of caches is being operated as a unified
system with good internal connectivity, such a request MAY be
forwarded within that group of caches.</t>
<t hangText="max-stale:">Indicates that the client is willing to
accept a media stream that has exceeded its expiration time. If
max-stale is assigned a value, then the client is willing to
accept a response that has exceeded its expiration time by no more
than the specified number of seconds. If no value is assigned to
max-stale, then the client is willing to accept a stale response
of any age.</t>
<t hangText="min-fresh:">Indicates that the client is willing to
accept a media stream whose freshness lifetime is no less than its
current age plus the specified time in seconds. That is, the
client wants a response that will still be fresh for at least the
specified number of seconds.</t>
<t hangText="must-revalidate:">When the must-revalidate directive
is present in a SETUP response received by a cache, that cache
MUST NOT use the entry after it becomes stale to respond to a
subsequent request without first revalidating it with the origin
server. That is, the cache is required to do an end-to-end
revalidation every time, if, based solely on the origin server's
Expires, the cached response is stale.)</t>
<t hangText="proxy-revalidate:">The proxy-revalidate directive has
the same meaning as the must-revalidate directive, except that it
does not apply to non-shared user agent caches. It can be used on
a response to an authenticated request to permit the user's cache
to store and later return the response without needing to
revalidate it (since it has already been authenticated once by
that user), while still requiring proxies that service many users
to revalidate each time (in order to make sure that each user has
been authenticated). Note that such authenticated responses also
need the public cache control directive in order to allow them to
be cached at all.</t>
<t hangText="max-age:">When an intermediate cache is forced, by
means of a max-age=0 directive, to revalidate its own cache entry,
and the client has supplied its own validator in the request, the
supplied validator might differ from the validator currently
stored with the cache entry. In this case, the cache MAY use
either validator in making its own request without affecting
semantic transparency.</t>
</list>However, the choice of validator might affect performance.
The best approach is for the intermediate cache to use its own
validator when making its request. If the server replies with 304 (Not
Modified), then the cache can return its now validated copy to the
client with a 200 (OK) response. If the server replies with a new
entity and cache validator, however, the intermediate cache can
compare the returned validator with the one provided in the client's
request, using the strong comparison function. If the client's
validator is equal to the origin server's, then the intermediate cache
simply returns 304 (Not Modified). Otherwise, it returns the new
entity with a 200 (OK) response.</t>
</section>
<section anchor="sec_Connection" title="Connection">
<t>See [H14.10]. The use of the connection option "close" in RTSP
messages SHOULD be limited to error messages when the server is unable
to recover and therefore see it necessary to close the connection. The
reason is that the client has the choice of continuing using a
connection indefinitely, as long as it sends valid messages.</t>
</section>
<section anchor="sec_Connection-Credentials"
title="Connection-Credentials">
<t>The Connection-Credentials response header is used to carry the
chain of credentials of any next hop that need to be approved by the
requestor. It SHALL only be used in server to client responses.</t>
<t>The Connection-Credentials header in an RTSP response SHALL, if
included, contain the credential information (in form of a list of
certificates providing the chain of certification) of the next hop
that an intermediary needs to securely connect to. The header MUST
include the URI of the next hop (proxy or server) and a base64 <xref
target="RFC4648"></xref> encoded binary structure containg a sequence
of DER encoded X.509v3 certificates<xref target="RFC3280"></xref>
.</t>
<t>The binary structure starts with the number of certificates
(NR_CERTS) included as a 16 bit unsigned integer. This is followed by
NR_CERTS number of 16 bit unsigned integers providing the size in
octets of each DER encoded certificate. This is followed by NR_CERTS
number of DER encoded X.509v3 certificates in a sequence (chain). The
proxy or server's certificate must come first in the structure. Each
following certificate must directly certify the one preceding it.
Because certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the root
certificate authority may optionally be omitted from the chain, under
the assumption that the remote end must already possess it in order to
validate it in any case.</t>
<t>Example: <figure>
<artwork><![CDATA[
Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...
Where MIIDNTCC... is a BASE64 encoding of the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of certifcates | Size of certificate #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of certificate #2 | Size of certificate #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="sec_Content-Base" title="Content-Base">
<t>The Content-Base entity-header field may be used to specify the
base URI for resolving relative URIs within the entity. <figure>
<artwork><![CDATA[Content-Base: rtsp://media.example.com/movie/twister]]></artwork>
</figure> If no Content-Base field is present, the base URI of an
entity is defined either by its Content-Location (if that
Content-Location URI is an absolute URI) or the URI used to initiate
the request, in that order of precedence. Note, however, that the base
URI of the contents within the entity-body may be redefined within
that entity-body.</t>
</section>
<section anchor="sec_Content-Encoding" title="Content-Encoding">
<t>See [H14.11].</t>
</section>
<section anchor="sec_Content-Language" title="Content-Language">
<t>See [H14.12].</t>
</section>
<section anchor="sec_Content-Length" title="Content-Length">
<t>The Content-Length general-header field contains the length of the
body (entity) of the message (i.e. after the double CRLF following the
last header). Unlike HTTP, it MUST be included in all messages that
carry body beyond the header portion of the message. If it is missing,
a default value of zero is assumed. It is interpreted according to
[H14.13].</t>
</section>
<section anchor="sec_Content-Location" title="Content-Location">
<t>See [H14.14].</t>
</section>
<section anchor="sec_Content-Type" title="Content-Type">
<t>See [H14.17]. Note that the content types suitable for RTSP are
likely to be restricted in practice to presentation descriptions and
parameter-value types.</t>
</section>
<section anchor="sec_CSeq" title="CSeq">
<t>The CSeq general-header field specifies the sequence number for an
RTSP request-response pair. This field MUST be present in all requests
and responses. For every RTSP request containing the given sequence
number, the corresponding response will have the same number. Any
retransmitted request MUST contain the same sequence number as the
original (i.e. the sequence number is not incremented for
retransmissions of the same request). For each new RTSP request the
CSeq value SHALL be incremented by one. The initial sequence number
MAY be any number, however it is RECOMMENDED to start at 0. Each
sequence number series is unique between each requester and responder,
i.e. the client has one series for its request to a server and the
server has another when sending request to the client. Each requester
and responder is identified with its network address.</t>
<t>Proxies that aggregate several sessions on the same transport will
regularly need to renumber the CSeq header field in requests and
responses to fulfill the rules for the header.</t>
<t>Example: <figure>
<artwork><![CDATA[CSeq: 239]]></artwork>
</figure></t>
</section>
<section anchor="sec_Date" title="Date">
<t>See [H14.18]. An RTSP message containing a body MUST include a Date
header if the sending host has a clock. Servers SHOULD include a Date
header in all other RTSP messages.</t>
</section>
<section anchor="sec_ETag" title="ETag">
<t>The ETag response header MAY be included in DESCRIBE or SETUP
responses. The entity tags (<xref target="sec_entity-tags"></xref>)
returned in a DESCRIBE response, and the one in SETUP refers to the
presentation, i.e. both the returned session description and the media
stream. This allows for verification that one has the right session
description to a media resource at the time of the SETUP request.
However it has the disadvantage that a change in any of the parts
results in invalidation of all the parts.</t>
<t>If the ETag is provided both inside the entity, e.g. within the
"a=etag" attribute in SDP, and in the response message, then both tags
SHALL be identical. It is RECOMMENDED that the ETag is primarily given
in the RTSP response message, to ensure that caches can use the ETag
without requiring content inspection. However for session descriptions
that are distributed outside of RTSP, for example using HTTP, etc. it
will be necessary to include the entity tag in the session description
as specified in <xref target="sec_sdp-etag"></xref>.</t>
<t>SETUP and DESCRIBE requests can be made conditional upon the ETag
using the headers If-Match (<xref target="sec_If-Match"></xref>) and
If-None-Match ( <xref target="sec_If-None-Match"></xref>).</t>
</section>
<section anchor="sec_Expires" title="Expires">
<t>The Expires entity-header field gives a date and time after which
the description or media-stream should be considered stale. The
interpretation depends on the method: <list hangIndent="6"
style="hanging">
<t hangText="DESCRIBE response:">The Expires header indicates a
date and time after which the presentation description (body)
SHOULD be considered stale.</t>
<t hangText="SETUP response:">The Expires header indicate a date
and time after which the media stream SHOULD be considered
stale.</t>
</list></t>
<t>A stale cache entry may not normally be returned by a cache (either
a proxy cache or an user agent cache) unless it is first validated
with the origin server (or with an intermediate cache that has a fresh
copy of the entity). See <xref target="sec_caching"></xref> for
further discussion of the expiration model.</t>
<t>The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that
time.</t>
<t>The format is an absolute date and time as defined by HTTP-date in
[H3.3]; it MUST be in RFC1123-date format:</t>
<t>An example of its use is <figure>
<artwork><![CDATA[ Expires: Thu, 01 Dec 1994 16:00:00 GMT]]></artwork>
</figure></t>
<t>RTSP/2.0 clients and caches MUST treat other invalid date formats,
especially including the value "0", as having occurred in the past
(i.e., already expired).</t>
<t>To mark a response as "already expired," an origin server should
use an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent.
RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in
the future.</t>
<t>The presence of an Expires header field with a date value of some
time in the future on a media stream that otherwise would by default
be non-cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a Cache-Control header field (<xref
target="sec_Cache-Control"></xref>).</t>
</section>
<section anchor="sec_From" title="From">
<t>See [H14.22].</t>
</section>
<section anchor="sec_If-Match" title="If-Match">
<t>See [H14.24].</t>
<t>The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, in both the case where
it is fetched via means external to RTSP (such as HTTP), or in the
case where the server implementation is guaranteeing the integrity of
the description between the time of the DESCRIBE message and the SETUP
message. By including the ETag given in or with the session
description in a SETUP request, the client ensures that resources set
up are matching the description. A SETUP request for which the ETag
validation check fails, SHALL responde using 412 (Precondition
Failed).</t>
<t>This validation check is also very useful if a session has been
redirected from one server to another.</t>
</section>
<section anchor="sec_If-Modified-Since" title="If-Modified-Since">
<t>The If-Modified-Since request-header field is used with the
DESCRIBE and SETUP methods to make them conditional. If the requested
variant has not been modified since the time specified in this field,
a description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (Not Modified)
response SHALL be returned without any message-body.</t>
<t>An example of the field is: <figure>
<artwork><![CDATA[ If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT]]></artwork>
</figure></t>
</section>
<section anchor="sec_If-None-Match" title="If-None-Match">
<t>See [H14.26].</t>
<t>This request header can be used with one or several entity tags to
make DESCRIBE requests conditional. A new session description is
retrieved only if another entity than the ones already available would
be included. If the entity available for delivery is matching the one
the client already has, then a 304 (Not Modified) response is
given.</t>
</section>
<section anchor="sec_Last-Modified" title="Last-Modified">
<t>The Last-Modified entity-header field indicates the date and time
at which the origin server believes the presentation description or
media stream was last modified. See [H14.29]. For the methods
DESCRIBE, the header field indicates the last modification date and
time of the description, for SETUP that of the media stream.</t>
</section>
<section anchor="sec_Location" title="Location">
<t>See [H14.30].</t>
</section>
<section anchor="sec_Media-Properties" title="Media-Properties">
<t>This general header is used in SETUP response or PLAY_NOTIFY
requests to indicate the media's properties that currently are
applicable. PLAY_NOTIFY MAY be used to modify these properties at any
point. However, the client MUST have received the update prior to any
action related to the new media properties take affect.</t>
<t>The header contains a list of property values that are applicable
to the currently setup media or aggregate of media as indicated by the
RTSP URI in the request. No ordering are enforced within the header.
Property values should be grouped into a single group that handles a
particular orthogonal property. Values or groups that express multiple
properties SHOULD NOT be used. The list of properties that can be
expressed MAY be extended at any time. Unknown property values SHALL
be ignored.</t>
<t>This specification defines the following 3 groups and their
property values:</t>
<t><list style="hanging">
<t hangText="Random Access:"><list style="hanging">
<t hangText="Random-Access:">Indicates that random access is
possible. May optionally include a floating point value in
seconds indicating the longest duration between any two random
access points in the media.</t>
<t hangText="Begining-Only:">Seeking is limited to the
begining only.</t>
<t hangText="No-Seeking:">No seeking is possible.</t>
</list></t>
<t hangText="Content Modifications"><list style="hanging">
<t hangText="Unmutable:">The content will not be changed
during the life-time of the RTSP session.</t>
<t hangText="Dynamic:">The content may be changed based on
external methods or triggers</t>
<t hangText="Time-Progressing">The media accesible progress as
wall clock time progresses.</t>
</list></t>
<t hangText="Retention"><list style="hanging">
<t hangText="Unlimited:">Content will be retained for the
duration of the life-time of the RTSP session.</t>
<t hangText="Time-Limited:">Content will be retained at least
until the specified wall clock time. The time must be provided
in the absolute time format specified in Section <xref
target="sec_clock"></xref>.</t>
<t hangText="Time-Duration">Each individual media unit is
retained for at least the specified time duration. This
definition allows for retaining data with a time based sliding
window. The time duration is expressed as floating point
number in seconds. 0.0 is a valid value as this indicates that
no data is retained in a time-progressing session.</t>
</list></t>
</list></t>
<t>An Example of this header for first an on-demand content and then a
live stream without recording.</t>
<t><figure>
<artwork><![CDATA[On-demand:
Media-Properties: Random-Acess=2.5s, Unlimited, Unmutable
Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="sec_Media-Range" title="Media-Range">
<t>The Media-Range general header is used to give the range of the
media at the time of sending the RTSP message. This header SHALL be
included in SETUP response, and PLAY and PAUSE response for media that
are Time-Progressing, and PLAY and PAUSE response after any change for
media that are Dynamic, and in PLAY_NOTIFY request that are sent due
to Media-Property-Update. Media-Range header without any range
specifications MAY be included in GET_PARAMETER requests to the server
to request the current value. The server SHALL in this case include
the curent value at the time of sending the response.</t>
<t>The header SHALL include range specification for all time formats
supported for the media, as indicated in <xref
target="sec_Accept-Ranges">Accept-Ranges header</xref> when setting up
the media. The server MAY include more than one range specification of
any given time format to indicate media that has non-continous
range.</t>
<t>For media that has the Time-Progressing property, the Media-Range
values will only be valid for the particular point in time when it was
issued. As wall clock progresses so will also the media range. However
it shall be assumed that media time progress in direct relationship to
wall clock time (with the exception of clock skew) so that a
reasoanbly accurate estiamation of the media range can be
calculated.</t>
</section>
<section anchor="sec_Notify-Reason" title="Notify-Reason">
<t>The Notify Reason header is solely used in the PLAY_NOTIFY method.
It indiciates the reason why the server has sent the asynchronous
PLAY-NOTIFY request (see <xref target="sec_PLAY_NOTIFY"></xref>).</t>
</section>
<section anchor="sec_Pipelined-Requests" title="Pipelined-Requests">
<t>The Pipelined-Requests general header is used to indicate that a
request is to be executed in the context created by previous requests.
The primary usage of this header is to allow pipelining of SETUP
requests so that any additional SETUP request after the first one
doesn't need to wait for the session ID to be sent back to the
requesting entity. The header contains a unique identifier that is
scoped by the persistent connection used to send the requests.</t>
<t>Upon receiving a request with the Pipelined-Requests the responding
entity SHALL look up if there exist a binding between this
Pipelined-Requests identifier for the current persistent connection
and an RTSP session ID. If that exist then the received request is
processed the same way as if it did contain the Session header with
the looked up session ID. If there doesn't exist a mapping and no
Session header is included in the request, the responding entity SHALL
create a binding upon the succesful completion of a session creating
request, i.e. SETUP. If the request failed to create an RTSP session
no binding SHALL be created. In case the request contains both a
Session header and the Pipelined-Requests header the
Pipelined-Requests SHALL be ignored.</t>
<t>Note: Based on the above definition at least the first request
containing a new unique Pipelined-Requests will be required to be a
SETUP request (unless the protocol is extended with new methods of
creating a session). After that first one, additional SETUP requests
or request of any type using the RTSP session context may include the
Pipelined-Requests header.</t>
<t>For all responses to request that contained the Pipelined-Requests,
the Session header and the Pipelined-Requests SHALL both be included,
assuming that it is allowed for that response and that the binding
between the header values exist. Pipelined-Requests SHOULD NOT be used
in requests after that the client has received the RTSP Session ID.
This as using the real session ID allows the request to be used also
in cases the persistent connection has been terminated and a new
connection is needed.</t>
<t>It is the sender of the request that is responsible for using a
previously unused identifier within this transport connection scope
when a new RTSP session is to be cretated with this method. A server
side binding SHALL be deleted upon the termination of the related RTSP
session. Note: Although this definition would allow for reusing
previously used pipelining identifiers, this is NOT RECOMMENDED to
allow for better error handling and logging.</t>
<t>RTSP Proxies may need to translate Pipelined-Requests identifier
values from incoming request to outgoing to allow for aggregation of
requests onto a persistent connection.</t>
</section>
<section anchor="sec_Proxy-Authenticate" title="Proxy-Authenticate">
<t>See [H14.33].</t>
</section>
<section title="Proxy-Authorization">
<t>See [H14.34].</t>
</section>
<section anchor="sec_Proxy-Require" title="Proxy-Require">
<t>The Proxy-Require request-header field is used to indicate
proxy-sensitive features that MUST be supported by the proxy. Any
Proxy-Require header features that are not supported by the proxy MUST
be negatively acknowledged by the proxy to the client using the
Unsupported header. The proxy SHALL use the 551 (Option Not Supported)
status code in the response. Any feature-tag included in the
Proxy-Require does not apply to the end-point (server or client). To
ensure that a feature is supported by both proxies and servers the tag
needs to be included in also a Require header.</t>
<t>See <xref target="sec_Require"></xref> for more details on the
mechanics of this message and a usage example.</t>
<t>Example of use: <figure>
<artwork><![CDATA[ Proxy-Require: play.basic]]></artwork>
</figure></t>
</section>
<section anchor="sec_Proxy-Supported" title="Proxy-Supported">
<t>The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It
SHALL be added by any proxy if the Supported header is present in a
request. When present in a request, the receiver MUST in the response
copy the received Proxy-Supported header.</t>
<t>The Proxy-Supported header field contains a list of feature-tags
applicable to proxies, as described in <xref
target="sec_feature_tags"></xref>. The list are the intersection of
all feature-tags understood by the proxies. To achieve an
intersection, the proxy adding the Proxy-Supported header includes all
proxy feature-tags it understands. Any proxy receiving a request with
the header, checks the list and removes any feature-tag it do not
support. A Proxy-Supported header present in the response SHALL NOT be
touched by the proxies.</t>
<t>Example: <figure>
<artwork><![CDATA[ C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
User-Agent: PhonyClient/1.2
P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
Via: 2.0 prox1.example.com
P2->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-blech
Via: 2.0 prox1.example.com, 2.0 prox2.example.com
S->C: RTSP/2.0 200 OK
Supported: foo, bar, baz
Proxy-Supported: proxy-foo, proxy-blech
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Via: 2.0 prox1.example.com, 2.0 prox2.example.com]]></artwork>
</figure></t>
</section>
<section anchor="sec_Public" title="Public">
<t>The Public response header field lists the set of methods supported
by the response sender. This header applies to the general
capabilities of the sender and its only purpose is to indicate the
sender's capabilities to the recipient. The methods listed may or may
not be applicable to the Request-URI; the Allow header field (section
14.7) MAY be used to indicate methods allowed for a particular
URI.</t>
<t>Example of use: <figure>
<artwork><![CDATA[ Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN]]></artwork>
</figure></t>
<t>In the event that there are proxies between the sender and the
recipient of a response, each intervening proxy MUST modify the Public
header field to remove any methods that are not supported via that
proxy. The resulting Public header field will contain an intersection
of the sender's methods and the methods allowed through by the
intervening proxies.</t>
<t><list style="hanging">
<t>In general proxies should allow all methods to transparently
pass through from the sending RTSP agent to the receiving RTSP
agent, but there may be cases where this is not desirable for a
given proxy. Modification of the Public response header field by
the intervening proxies ensures that the request sender gets an
accurate response indicating the methods that can be used on the
target agent via the proxy chain.</t>
</list></t>
</section>
<section anchor="sec_Range" title="Range">
<t>The Range header specifies a time range in PLAY (<xref
target="sec_PLAY"></xref>), PAUSE (<xref target="sec_PAUSE"></xref>),
SETUP (<xref target="sec_SETUP"></xref>), REDIRECT (<xref
target="sec_REDIRECT"></xref>), and PLAY_NOTIFY (<xref
target="sec_PLAY_NOTIFY"></xref>) requests and responses.</t>
<t>The range can be specified in a number of units. This specification
defines smpte (<xref target="sec_smpte"></xref>), npt (<xref
target="sec_npt"></xref>), and clock (<xref
target="sec_clock"></xref>) range units. While byte ranges [H14.35.1]
and other extended units MAY be used, their behavior is unspecified
since they are not normally meaningful in RTSP. Servers supporting the
Range header MUST understand the NPT range format and SHOULD
understand the SMPTE range format. If the Range header is sent in a
time format that is not understood, the recipient SHOULD return 456
(Header Field Not Valid for Resource) and include an Accept-Ranges
header indicating the supported time formats for the given
resource.</t>
<t>The Range header MAY contain a time parameter in UTC, specifying
the time at which the operation is to be made effective. This
functionality SHALL be used only with the REDIRECT method.</t>
<t>Example: <figure>
<artwork><![CDATA[ Range: clock=19960213T143205Z-;time=19970123T143720Z]]></artwork>
</figure></t>
<t><list style="hanging">
<t>The notation is similar to that used for the HTTP/1.1 <xref
target="RFC2616"></xref> byte-range header. It allows clients to
select an excerpt from the media object, and to play from a given
point to the end as well as from the current location to a given
point.</t>
</list></t>
<t>Ranges are half-open intervals, including the first point, but
excluding the second point. In other words, a range of A-B starts
exactly at time A, but stops just before B. Only the start time of a
media unit such as a video or audio frame is relevant. For example,
assume that video frames are generated every 40 ms. A range of
10.0-10.1 would include a video frame starting at 10.0 or later time
and would include a video frame starting at 10.08, even though it
lasted beyond the interval. A range of 10.0-10.08, on the other hand,
would exclude the frame at 10.08.</t>
<t>By default, range intervals increase, where the second point is
larger than the first point.</t>
<t>Example: <figure>
<artwork><![CDATA[ Range: npt=10-15]]></artwork>
</figure></t>
<t>However, range intervals can also decrease if the Scale header (see
<xref target="sec_Scale"></xref>) indicates a negative scale value.
For example, this would be the case when a playback in reverse is
desired.</t>
<t>Example: <figure>
<artwork><![CDATA[ Scale: -1
Range: npt=15-10]]></artwork>
</figure></t>
<t>Decreasing ranges are still half open intervals as described above.
Thus, for range A-B, A is closed and B is open. In the above example,
15 is closed and 10 is open. An exception to this rule is the case
when B=0 in a decreasing range. In this case, the range is closed on
both ends, as otherwise there would be no way to reach 0 on a reverse
playback for formats that have such a notion, like NPT and SMPTE.</t>
<t>Example: <figure>
<artwork><![CDATA[ Scale: -1
Range: npt=15-0]]></artwork>
</figure></t>
<t>In this range both 15 and 0 are closed.</t>
<t>A decreasing range interval without a corresponding negative Scale
header is not valid.</t>
</section>
<section anchor="sec_Referer" title="Referer">
<t>See [H14.36]. The URI refers to that of the presentation
description, typically retrieved via HTTP.</t>
</section>
<section anchor="sec_Retry-After" title="Retry-After">
<t>See [H14.37].</t>
</section>
<section anchor="sec_Request-Status" title="Request-Status">
<t>This request header is used to indicate the end result for requests
that takes time to complete, such a <xref
target="sec_PLAY">PLAY</xref>. It is sent in <xref
target="sec_PLAY_NOTIFY">PLAY_NOTIFY</xref> with the end-of-stream
reason to report how the PLAY request concluded, either in success or
in failure. The header carries a reference to the request is reports
on using the CSeq number for the session indicated by the Session
header in the request. It provies both a numerical status code
(according to <xref target="sec_status-code"></xref>) and a human
readable reason phrase.</t>
<t><figure>
<artwork><![CDATA[Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable"]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="sec_Require" title="Require">
<t>The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required in
respect to this request. It can also be used to query if the other
end-point supports certain features, however the use of the Supported
(<xref target="sec_Supported"></xref>) is much more effective in this
purpose. The server MUST respond to this header by using the
Unsupported header to negatively acknowledge those feature-tags which
are NOT supported. The response SHALL use the error code 551 (Option
Not Supported). This header does not apply to proxies, for the same
functionality in respect to proxies see Proxy-Require header (<xref
target="sec_Proxy-Require"></xref>).</t>
<t><list style="hanging">
<t>This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as in
the example below). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes state
ambiguity when the client requires features that the server does
not understand.</t>
</list></t>
<t>Example (Not complete): <figure>
<artwork><![CDATA[C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Require: funky-feature
Funky-Parameter: funkystuff
S->C: RTSP/2.0 551 Option not supported
CSeq: 302
Unsupported: funky-feature]]></artwork>
</figure></t>
<t>In this example, "funky-feature" is the feature-tag which indicates
to the client that the fictional Funky-Parameter field is required.
The relationship between "funky-feature" and Funky-Parameter is not
communicated via the RTSP exchange, since that relationship is an
immutable property of "funky-feature" and thus should not be
transmitted with every exchange.</t>
<t>Proxies and other intermediary devices SHALL ignore this header. If
a particular extension requires that intermediate devices support it,
the extension should be tagged in the Proxy-Require field instead (see
<xref target="sec_Proxy-Require"></xref>).</t>
</section>
<section anchor="sec_RTP-Info" title="RTP-Info">
<t>The RTP-Info response-header field is used to set RTP-specific
parameters in the PLAY response. For streams using RTP as transport
protocol the RTP-Info header SHOULD be part of a 200 response to
PLAY.</t>
<t><list style="hanging">
<t>The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to
synchronize the media streams using RTCP. This may have negative
impact as the RTCP can be lost, and does not need to be
particulary timely in their arrival. Also functionality as
informing the client from which packet a seek has occurred is
affected.</t>
</list></t>
<t>The RTP-Info MAY also be included in SETUP responses to provide
synchronization information when changing transport parameters, see
<xref target="sec_SETUP"></xref>.</t>
<t>The header can carry the following parameters: <list hangIndent="6"
style="hanging">
<t hangText="url:">Indicates the stream URI which for which the
following RTP parameters correspond, this URI MUST be the same
used in the SETUP request for this media stream. Any relative URI
SHALL use the Request-URI as base URI. This parameter SHALL be
present.</t>
<t hangText="ssrc:">The Synchronization source (SSRC) that the RTP
timestamp and sequence number provide applies to. This parameter
SHALL be present.</t>
<t hangText="seq:">Indicates the sequence number of the first
packet of the stream that is direct result of the request. This
allows clients to gracefully deal with packets when seeking. The
client uses this value to differentiate packets that originated
before the seek from packets that originated after the seek. Note
that a client may not receive the packet with the expressed
sequence number, and instead packets with a higher sequence
number, due to packet loss or reordering. This parameter is
RECOMMENDED to be present.</t>
<t hangText="rtptime:">SHALL indicate the RTP timestamp value
corresponding to the start time value in the Range response
header, or if not explicitly given the implied start point. The
client uses this value to calculate the mapping of RTP time to NPT
or other media timescale. This parameter SHOULD be present to
ensure inter-media synchronization is achieved. There exist no
requirement that any received RTP packet will have the same RTP
timestamp value as the one in the parameter used to establish
synchronization.</t>
</list></t>
<t><list style="hanging">
<t>A mapping from RTP timestamps to NTP timestamps (wall clock) is
available via RTCP. However, this information is not sufficient to
generate a mapping from RTP timestamps to media clock time (NPT,
etc.). Furthermore, in order to ensure that this information is
available at the necessary time (immediately at startup or after a
seek), and that it is delivered reliably, this mapping is placed
in the RTSP control channel.</t>
</list> <list style="hanging">
<t>In order to compensate for drift for long, uninterrupted
presentations, RTSP clients should additionally map NPT to NTP,
using initial RTCP sender reports to do the mapping, and later
reports to check drift against the mapping.</t>
</list></t>
<t>Example: <figure>
<artwork><![CDATA[Range:npt=3.25-15
RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
rtptime=12345678,url="rtsp://example.com/foo/video"
ssrc=9A9DE123:seq=30211;rtptime=29567112
Lets assume that Audio uses a 16kHz RTP timestamp clock and Video
a 90kHz RTP timestamp clock. Then the media synchronization is
depicted in the following way.
NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio PA A
Video V PV
X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878. Which
corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412. Which
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32]]></artwork>
</figure></t>
</section>
<section anchor="sec_Scale" title="Scale">
<t>A scale value of 1 indicates normal play at the normal forward
viewing rate. If not 1, the value corresponds to the rate with respect
to normal viewing rate. For example, a ratio of 2 indicates twice the
normal viewing rate ("fast forward") and a ratio of 0.5 indicates half
the normal viewing rate. In other words, a ratio of 2 has normal play
time increase at twice the wallclock rate. For every second of elapsed
(wallclock) time, 2 seconds of content will be delivered. A negative
value indicates reverse direction. For certain media transports this
may require certain considerations to work consistent, see <xref
target="sec_rtp"></xref> for description on how RTP handles this.</t>
<t>Unless requested otherwise by the Speed parameter, the data rate
SHOULD not be changed. Implementation of scale changes depends on the
server and media type. For video, a server may, for example, deliver
only key frames or selected key frames. For audio, for example, it may
time-scale the audio while preserving pitch or, less desirably,
deliver fragments of audio.</t>
<t>The server should try to approximate the viewing rate, but may
restrict the range of scale values that it supports. The response MUST
contain the actual scale value chosen by the server.</t>
<t>If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for
PLAY SHALL indicate this with the use of the "play.scale"
feature-tags.</t>
<t>When indicating a negative scale for a reverse playback, the Range
header MUST indicate a decreasing range as described in <xref
target="sec_Range"></xref>.</t>
<t>Example of playing in reverse at 3.5 times normal rate: <figure>
<artwork><![CDATA[ Scale: -3.5
Range: npt=15-10]]></artwork>
</figure></t>
</section>
<section anchor="sec_Seek-Style" title="Seek-Style">
<t>When a client sends a PLAY request with a Range header to perform a
random access to the media, the client does not know if the server
will pick the first media samples or the first random access point
prior to the request range. Depending on use case, the client may have
a strong preference. To express this preference and provide the client
with information on how the server actually acted on that preference
the Seek-Style header is defined.</t>
<t>Seek-Style is a general header that MAY be included in any PLAY
request to indicate the client's preference for any media stream that
has random access properties. The server SHALL always include the
header in any PLAY response for media with random access properties to
indicate what policy was applied. A Server that receives a unknown
Seek-Style policy SHALL ignore it and select the server default
policy.</t>
<t>This specification defines the following seek policies that may be
requested:</t>
<t><list style="hanging">
<t hangText="RAP:">Random Access Point (RAP) is the behavior of
requesting the server to locate the closest previous random access
point that exist in the media aggregate and deliver from that. By
requesting a RAP media quality will be the best possible as all
media will be delivered from a point where full media state can be
established in the media decoder.</t>
<t hangText="First-Prior:">The first-prior policy will start
delivery with the media unit that has a playout time first prior
to the requested time. For discrete media that would only include
media units that would still be rendered at the request time. For
continous media that is media that will be render during the
requested start time of the range.</t>
<t hangText="Next:">The next media units after the provided start
time of the range. For continous framed media that would mean the
first next frame after the provided time. For discrete media the
first unit that is to be rendered after the provided time. The
main usage is for this case is when the client knows it has all
media up to a certain point and would like to continue delivery so
that a complete non-interrupted media playback can be achieved.
Example of such scenarios include switching from a
broadcast/multicast delivery to a unicast based delivery. This
policy SHALL only be used on the client's explicit request.</t>
</list>Please note that these expressed preferences exist for
optimizing the startup time or the media quality. The "Next" policy
breaks the normal definition of the Range header to enable a client to
request media with minimal overlap, although some may still occur for
aggregated sessions. RAP and First-Prior both fulfill the requirement
of providing media from the requested range and forward. However,
unless RAP is used, the media quality for many media codecs using
predictive methods can be severly degraded unless additional data is
available as, for example, already buffered, or through other side
channels.</t>
</section>
<section anchor="sec_Speed" title="Speed">
<t>The Speed request-header field requests the server to deliver data
to the client at a particular speed, contingent on the server's
ability and desire to serve the media stream at the given speed.
Implementation by the server is OPTIONAL. The default is the bit rate
of the stream.</t>
<t>The parameter value is expressed as a decimal ratio, e.g., a value
of 2.0 indicates that data is to be delivered twice as fast as normal.
A speed of zero is invalid. All speeds may not be possible to support.
Therefore the actual used speed MUST be included in the response. The
lack of a response header is indication of lack of support from the
server of this functionality. Support of the speed functionality are
indicated by the "play.speed" feature-tag.</t>
<t>Example: <figure>
<artwork><![CDATA[ Speed: 2.5]]></artwork>
</figure></t>
<t>Use of this field changes the bandwidth used for data delivery. It
is meant for use in specific circumstances where preview of the
presentation at a higher or lower rate is necessary. Implementors
should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. When data is delivered over UDP, it is highly
recommended that means such as RTCP be used to track packet loss
rates. If the data transport is performed over non-dedicated
best-effort networks the sender is required to perform congestion
control of the stream(s). This can result in that the communicated
speed is impossible to maintain.</t>
</section>
<section anchor="sec_Server" title="Server">
<t>See [H14.38], however the header syntax is corrected in <xref
target="sec_syntax-prot-header"></xref>.</t>
</section>
<section anchor="sec_Session" title="Session">
<t>The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result of
a successful SETUP request and in the response the session identifier
is given to the client. The RTSP session exist until destroyed by a
TEARDOWN or timed out by the server.</t>
<t>The session identifier is chosen by the server (see <xref
target="sec_session-id"></xref>) and MUST be returned in the SETUP
response. Once a client receives a session identifier, it SHALL be
included in any request related to that session. This means that the
Session header MUST be included in a request using the following
methods: PLAY, PAUSE, and TEARDOWN, and MAY be included in SETUP,
OPTIONS, SET_PARAMETER, GET_PARAMETER, and REDIRECT, and SHALL NOT be
included in DESCRIBE. In an RTSP response the session header SHALL be
included in methods, SETUP, PLAY, and PAUSE, and MAY be included in
methods, TEARDOWN, and REDIRECT, and if included in the request of the
following methods it SHALL also be included in the response, OPTIONS,
GET_PARAMETER, and SET_PARAMETER, and SHALL NOT be included in
DESCRIBE.</t>
<t>Note that a session identifier identifies an RTSP session across
transport sessions or connections. RTSP requests for a given session
can use different URIs (Presentation and media URIs). Note, that there
are restrictions depending on the session which URIs that are
acceptable for a given method. However, multiple "user" sessions for
the same URI from the same client will require use of different
session identifiers.</t>
<t><list style="hanging">
<t>The session identifier is needed to distinguish several
delivery requests for the same URI coming from the same
client.</t>
</list></t>
<t>The response 454 (Session Not Found) SHALL be returned if the
session identifier is invalid.</t>
</section>
<section anchor="sec_Supported" title="Supported">
<t>The Supported header field enumerates all the extensions supported
by the client or server using feature tags. The header carries the
extensions supported by the message sending entity. The Supported
header MAY be included in any request. When present in a request, the
receiver MUST respond with its corresponding Supported header. Note,
also in 4xx and 5xx responses is the supported header included.</t>
<t>The Supported header field contains a list of feature-tags,
described in <xref target="sec_feature_tags"></xref>, that are
understood by the client or server.</t>
<t>Example: <figure>
<artwork><![CDATA[
C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz]]></artwork>
</figure></t>
</section>
<section anchor="sec_Timestamp" title="Timestamp">
<t>The Timestamp general-header field describes when the agent sent
the request. The value of the timestamp is of significance only to the
agent and may use any timescale. The responding agent MUST echo the
exact same value and MAY, if it has accurate information about this,
add a floating point number indicating the number of seconds that has
elapsed since it has received the request. The timestamp is used by
the agent to compute the round-trip time to the responding agent so
that it can adjust the timeout value for retransmissions. It also
resolves retransmission ambiguities for unreliable transport of
RTSP.</t>
</section>
<section anchor="sec_Transport" title="Transport">
<t>The Transport request and response header field indicates which
transport protocol is to be used and configures its parameters such as
destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not already
determined by a presentation description.</t>
<t>Transports are comma separated, listed in order of preference.
Parameters may be added to each transport, separated by a semicolon.
The server SHOULD return a Transport response-header field in the
response to indicate the values actually chosen. The Transport header
field MAY also be used to change certain transport parameters. A
server MAY refuse to change parameters of an existing stream.</t>
<t>A Transport request header field MAY contain a list of transport
options acceptable to the client, in the form of multiple
transport-spec entries. In that case, the server MUST return the
single (transport-spec) which was actually chosen. The number of
transport-spec entries is expected to be limited as the client will
get guidance on what configurations that are possible from the
presentation description.</t>
<t>A transport-spec transport option may only contain one of any given
parameter within it. Parameters MAY be given in any order.
Additionally, it may only contain the unicast or the multicast
transport type parameter. Unknown parameters SHALL be ignored. The
requester need to ensure that the responder understands the parameters
through the use of feature tags and the Require header.</t>
<t>Any parameters part of future extensions requires clarification if
they are safe to ignore in accordance to this specification, or are
required to be understood. If a parameter is required to be
understood, then a feature-tag MUST be defined for the functionality
and used in the Require or Proxy-Require headers.</t>
<t><list style="hanging">
<t>The Transport header field is restricted to describing a single
media stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a multitude
of session description formats greatly simplifies designs of
firewalls.</t>
</list></t>
<t>The general syntax for the transport specifier is a list of slash
separated tokens: <figure>
<artwork><![CDATA[Value1/Value2/Value3...]]></artwork>
</figure> Which for RTP transports take the form: <figure>
<artwork><![CDATA[RTP/profile/lower-transport.]]></artwork>
</figure></t>
<t>The default value for the "lower-transport" parameters is specific
to the profile. For RTP/AVP, the default is UDP.</t>
<t>There are two different methods for how to specify where the media
should be delivered: <list hangIndent="6" style="hanging">
<t hangText="dest_addr:">The presence of this parameter and its
values indicates the destination address or addresses (host
address and port pairs for IP flows) necessary for the media
transport.</t>
<t hangText="No dest_addr:">The lack of the dest_addr parameter
indicates that the server SHALL send media to same address for
which the RTSP messages originates. Does not work for transports
requiring explicitly given destination ports.</t>
</list></t>
<t>The choice of method for indicating where the media is to be
delivered depends on the use case. In many case the only allowed
method will be to use no explicit address indication and have the
server deliver media to the source of the RTSP messages.</t>
<t>An RTSP proxy will need to take care. If the media is not desired
to be routed through the proxy, the proxy will need to introduce the
destination indication.</t>
<t>Below are the configuration parameters associated with transport:
<vspace blankLines="1" /> General parameters: <list hangIndent="6"
style="hanging">
<t hangText="unicast / multicast:">This parameter is a mutually
exclusive indication of whether unicast or multicast delivery will
be attempted. One of the two values MUST be specified. Clients
that are capable of handling both unicast and multicast
transmission needs to indicate such capability by including two
full transport-specs with separate parameters for each.</t>
<t hangText="layers:">The number of multicast layers to be used
for this media stream. The layers are sent to consecutive
addresses starting at the dest_addr address. If the parameter is
not included, it defaults to a single layer.</t>
<t hangText="dest_addr:">A general destination address parameter
that can contain one or more address specifications. Each
combination of Protocol/Profile/Lower Transport needs to have the
format and interpretation of its address specification defined.
For RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a
tuple containing a host address and port. Note, only a single
destination entity per transport spec is intended. The usage of
multiple destination to distribute a single media to multiple
entities is unspecified. <vspace blankLines="1" /> The client
originating the RTSP request MAY specify the destination address
of the stream recipient with the host address part of the tuple.
When the destination address is specified, the recipient may be a
different party than the originator of the request. To avoid
becoming the unwitting perpetrator of a remote-controlled
denial-of-service attack, a server MUST perform security checks
(see <xref target="sec-dos"></xref>) and SHOULD log such attempts
before allowing the client to direct a media stream to a recipient
address not chosen by the server. Implementations cannot rely on
TCP as reliable means of client identification. If the server does
not allow the host address part of the tuple to be set, it SHALL
return 463 (Destination Prohibited). <vspace blankLines="1" /> The
host address part of the tuple MAY be empty, for example ":58044",
in cases when only destination port is desired to be
specified.</t>
<t hangText="src_addr:">A general source address parameter that
can contain one or more address specifications. Each combination
of Protocol/Profile/Lower Transport needs to have the format and
interpretation of its address specification defined. For
RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a tuple
containing a host address and port. <vspace blankLines="1" /> This
parameter MUST be specified by the server if it transmits media
packets from another address than the one RTSP messages are sent
to. This will allow the client to verify source address and give
it a destination address for its RTCP feedback packets if RTP is
used. The address or addresses indicated in the src_addr parameter
SHOULD be used both for sending and receiving of the media streams
data packets. The main reasons are threefold: First, indicating
the port and source address(s) lets the receiver know where from
the packets is expected to originate. Secondly, traversal of NATs
are greatly simplified when traffic is flowing symmetrically over
a NAT binding. Thirdly, certain NAT traversal mechanisms, needs to
know to which address and port to send so called "binding packets"
from the receiver to the sender, thus creating a address binding
in the NAT that the sender to receiver packet flow can use.
<vspace blankLines="1" /> <list style="hanging">
<t>This information may also be available through SDP.
However, since this is more a feature of transport than media
initialization, the authoritative source for this information
should be in the SETUP response.</t>
</list></t>
<t hangText="mode:">The mode parameter indicates the methods to be
supported for this session. Valid values are PLAY and RECORD. If
not provided, the default is PLAY. The RECORD value was defined in
RFC 2326 and is in this specification unspecified but
reserved.</t>
<t hangText="interleaved:">The interleaved parameter implies
mixing the media stream with the control stream in whatever
protocol is being used by the control stream, using the mechanism
defined in <xref target="sec_binary"></xref>. The argument
provides the channel number to be used in the $ statement and MUST
be present. This parameter MAY be specified as a range, e.g.,
interleaved=4-5 in cases where the transport choice for the media
stream requires it, e.g. for RTP with RTCP. The channel number
given in the request are only a guidance from the client to the
server on what channel number(s) to use. The server MAY set any
valid channel number in the response. The declared channel(s) are
bi-directional, so both end-parties MAY send data on the given
channel. One example of such usage is the second channel used for
RTCP, where both server and client sends RTCP packets on the same
channel. <vspace blankLines="1" /> <list style="hanging">
<t>This allows RTP/RTCP to be handled similarly to the way
that it is done with UDP, i.e., one channel for RTP and the
other for RTCP.</t>
</list></t>
</list></t>
<t>Multicast-specific: <list hangIndent="6" style="hanging">
<t hangText="ttl:">multicast time-to-live. When included in
requests the value indicate the TTL value that the client desires
to use. In response the value actually being used is returned. A
server will need to consider what values that are reasonable and
also the authority of the user to set this value.</t>
</list></t>
<t>RTP-specific: <vspace blankLines="1" /> These parameters are MAY
only be used if the media transport protocol is RTP. <list
hangIndent="6" style="hanging">
<t hangText="ssrc:">The ssrc parameter, if included in a SETUP
response, indicates the RTP SSRC <xref target="RFC3550"></xref>
value(s) that will be used by the media server for RTP packets
within the stream. It is expressed as an eight digit hexadecimal
value. <vspace blankLines="1" /> The ssrc parameter SHALL NOT be
specified in requests. The functionality of specifying the ssrc
parameter in a SETUP request is deprecated as it is incompatible
with the specification of RTP in RFC 3550<xref
target="RFC3550"></xref>. If the parameter is included in the
Transport header of a SETUP request, the server MAY ignore it, and
choose appropriate SSRCs for the stream. The server MAY set the
ssrc parameter in the Transport header of the response.</t>
</list></t>
<t>The parameters defined below MAY only be used if the media
transport protocol if the lower-level transport is connection-oriented
(such as TCP). However, these parameters MUST NOT be used when
interleaving data over the RTSP control connection. <list
hangIndent="6" style="hanging">
<t hangText="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 connection. This parameter is adapted from <xref
target="RFC4145"></xref>. We discuss the use of this parameter in
RTP/AVP/TCP non-interleaved transport in <xref
target="sec_media-tcp-contrans"></xref>; the discussion below is
limited to syntactic issues. Clients may specify the following
values for the setup parameter: ["active":] The client will
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. <vspace blankLines="1" /> If a client does not specify
a setup value, the "active" value is assumed. <vspace
blankLines="1" /> In response to a client SETUP request where the
setup parameter is set to "active", a server's 2xx reply MUST
assign the setup parameter to "passive" on the Transport header
line. <vspace blankLines="1" /> In response to a client SETUP
request where the setup parameter is set to "passive", a server's
2xx reply MUST assign the setup parameter to "active" on the
Transport header line. <vspace blankLines="1" /> In response to a
client SETUP request where the setup parameter is set to
"actpass", a server's 2xx reply MUST assign the setup parameter to
"active" or "passive" on the Transport header line. <vspace
blankLines="1" /> Note that the "holdconn" value for setup is not
defined for RTSP use, and MUST NOT appear on a Transport line.</t>
<t hangText="connection:">Clients use the setup parameter on the
Transport line in a SETUP request, to indicate the SETUP request
prefers the reuse of an existing connection between client and
server (in which case the client sets the "connection" parameter
to "existing"), or that the client requires the creation of a new
connection between client and server (in which cast the client
sets the "connection" parameter to "new"). Typically, clients use
the "new" value for the first SETUP request for a URL, and
"existing" for subsequent SETUP requests for a URL. <vspace
blankLines="1" /> If a client SETUP request assigns the "new"
value to "connection", the server response MUST also assign the
"new" value to "connection" on the Transport line. <vspace
blankLines="1" /> If a client SETUP request assigns the "existing"
value to "connection", the server response MUST assign a value of
"existing" or "new" to "connection" on the Transport line, at its
discretion. <vspace blankLines="1" /> The default value of
"connection" is "existing", for all SETUP requests (initial and
subsequent).</t>
</list></t>
<t>The combination of transport protocol, profile and lower transport
needs to be defined. A number of combinations are defined in the <xref
target="sec_mediatran"></xref>.</t>
<t>Below is a usage example, showing a client advertising the
capability to handle multicast or unicast, preferring multicast. Since
this is a unicast-only stream, the server responds with the proper
transport parameters for unicast. <figure>
<artwork><![CDATA[
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY"
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256"/
"192.0.2.224:6257";mode="PLAY"
Accept-Ranges: NPT]]></artwork>
</figure></t>
</section>
<section anchor="sec_Unsupported" title="Unsupported">
<t>The Unsupported response-header field lists the features not
supported by the server. In the case where the feature was specified
via the Proxy-Require field (<xref
target="sec_Proxy-Require"></xref>), if there is a proxy on the path
between the client and the server, the proxy MUST send a response
message with a status code of 551 (Option Not Supported). The request
SHALL NOT be forwarded.</t>
<t>See <xref target="sec_Require"></xref> for a usage example.</t>
</section>
<section anchor="sec_User-Agent" title="User-Agent">
<t>See [H14.43] for explanation, however the syntax is clarified due
to an error in RFC 2616. A Client SHOULD include this header in all
RTSP messages it sends.</t>
</section>
<section anchor="sec_Vary" title="Vary">
<t>See [H14.44].</t>
</section>
<section anchor="sec_Via" title="Via">
<t>See [H14.45].</t>
</section>
<section anchor="sec_WWW-Authenticate" title="WWW-Authenticate">
<t>See [H14.47].</t>
</section>
</section>
<section anchor="sec_proxies" title="Proxies">
<t>RTSP Proxies are RTSP agents that sit in between a client and a
server. A proxy can take on both the role as a client and as server
depending on what it tries to accomplish. Proxies are also introduced
for several different reasons. <list hangIndent="6" style="hanging">
<t hangText="Caching Proxy:">This type of proxy is used to reduce
the workload on servers and connections. By caching a presentation,
both description and media streams the proxy can serve a client
content without requesting it from the server once it has been
cached and hasn't become stale. See the caching <xref
target="sec_caching"></xref>.</t>
<t hangText="Access Proxy:">This type of proxy is used to ensure
that a RTSP client get access to servers on an external network.
Thus this proxy is placed on the border between two domains, e.g. a
private address space and the public internet. The proxy performs
the necessary translation, usually addresses, and often also media
stream translation or redirection.</t>
<t hangText="Security Proxy:">This type of proxy is used to help
facilitate security functions around RTSP. For example when having a
firewalled network, the security proxy request that the necessary
pinholes in the firewall is opened when a client in the protected
network want to access media streams on the external side. It can
also provide network owners with a logging and audit point for RTSP
sessions, e.g. for corporations that tracks or limits their
employees access to certain type of content.</t>
</list></t>
<t>All type of proxies can be used also when using secured communication
with TLS as RTSP 2.0 allows the client to approve certificate chains
used for connection establishment from a proxy, see <xref
target="sec_security-tls-proxy"></xref>. However that trust model may
not be suitable for all type of deployment, and instead secured sessions
do by-pass of the proxies.</t>
<t>Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home or
small office equipment. In these cases it is better to use the NAT
traversal procedures defined for RTSP 2.0 <xref
target="I-D.ietf-mmusic-rtsp-nat"></xref>. The reason for these
recommendations is that any extensions of RTSP resulting in new media
transport protocols or profiles, new parameters etc may fail in a proxy
that isn't maintained. Thus resulting in blocking further development of
RTSP and its usage.</t>
<t>The existence of proxies must always be considered when developing
new RTSP extensions. There must be definition of how proxies may handle
the extension, if it is required to understand it, thus requiring a
feature-tag to be used in the Proxy-Require header.</t>
</section>
<!-- title="Proxies" -->
<section anchor="sec_caching" title="Caching">
<t>In HTTP, response-request pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. (Since
the responses for anything but DESCRIBE and GET_PARAMETER do not return
any data, caching is not really an issue for these requests.) However,
it is desirable for the continuous media data, typically delivered
out-of-band with respect to RTSP, to be cached, as well as the session
description.</t>
<t>On receiving a SETUP or PLAY request, a proxy ascertains whether it
has an up-to-date copy of the continuous media content and its
description. It can determine whether the copy is up-to-date by issuing
a SETUP or DESCRIBE request, respectively, and comparing the
Last-Modified header with that of the cached copy. If the copy is not
up-to-date, it modifies the SETUP transport parameters as appropriate
and forwards the request to the origin server. Subsequent control
commands such as PLAY or PAUSE then pass the proxy unmodified. The proxy
delivers the continuous media data to the client, while possibly making
a local copy for later reuse. The exact behavior allowed to the cache is
given by the cache-response directives described in <xref
target="sec_Cache-Control"></xref>. A cache MUST answer any DESCRIBE
requests if it is currently serving the stream to the requestor, as it
is possible that low-level details of the stream description may have
changed on the origin-server.</t>
<t>Note that an RTSP cache, unlike the HTTP cache, is of the
"cut-through" variety. Rather 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 client. Thus, it does not introduce
additional latency.</t>
<t>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 cache
has to store the content type, content language, and so on for the
objects it caches, a media cache has to store the presentation
description. Typically, a cache eliminates all transport-references
(that is, e.g. multicast information) from the presentation description,
since these are independent of the data delivery from the cache to the
client. Information on the encodings remains the same. If the cache is
able to translate the cached media data, it would create a new
presentation description with all the encoding possibilities it can
offer.</t>
</section>
<!-- title="Caching" -->
<section anchor="sec_security-framework" title="Security Framework">
<t>The RTSP security framework consists of two high level components:
the pure authentication mechanisms based on HTTP authentication, and the
transport protection based on TLS, which is independent of RTSP. Because
of the similarity in syntax and usage between RTSP servers and HTTP
servers, the security for HTTP is re-used to a large extent.</t>
<section title="RTSP and HTTP Authentication">
<t>RTSP and HTTP share common authentication schemes, and thus follow
the same usage guidelines as specified in<xref
target="RFC2617"></xref> and also in [H15]. Servers SHOULD implement
both basic and digest <xref target="RFC2617"></xref> authentication.
Client SHALL implement both basic and digest authentication <xref
target="RFC2617"></xref> so that Server who requires the client to
authenticate can trust that the capability is present.</t>
<t>It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in environments
requiring tighter security for the control messages, TLS SHOULD be
used, see <xref target="sec_sec-frame-TLS"></xref>.</t>
</section>
<section anchor="sec_sec-frame-TLS" title="RTSP over TLS">
<t>RTSP SHALL follow the same guidelines with regards to TLS <xref
target="RFC4346"></xref> usage as specified for HTTP, see <xref
target="RFC2818"></xref>. RTSP over TLS is separated from unsecured
RTSP both on URI level and port level. Instead of using the "rtsp"
scheme identifier in the URI, the "rtsps" scheme identifier MUST be
used to signal RTSP over TLS. If no port is given in a URI with the
"rtsps" scheme, port 322 SHALL be used for TLS over TCP/IP.</t>
<t>When a client tries to setup an insecure channel to the server
(using the "rtsp" URI), and the policy for the resource requires a
secure channel, the server SHALL redirect the client to the secure
service by sending a 301 redirect response code together with the
correct Location URI (using the "rtsps" scheme). A user or client MAY
upgrade a non secured URI to a secured by changing the scheme from
"rtsp" to "rtsps". A server implementing support for "rtsps" SHALL
allow this.</t>
<t>It should be noted that TLS allows for mutual authentication (when
using both server and client certificates). Still, one of the more
common way TLS is used is to only provide server side authentication
(often to avoid client certificates). TLS is then used in addition to
HTTP authentication, providing transport security and server
authentication, while HTTP Authentication is used to authenticate the
client.</t>
<t>RTSP includes the possibility to keep a TCP session up between the
client and server, throughout the RTSP session lifetime. It may be
convenient to keep the TCP session, not only to save the extra setup
time for TCP, but also the extra setup time for TLS (even if TLS uses
the resume function, there will be almost two extra roundtrips).
Still, when TLS is used, such behavior introduces extra active state
in the server, not only for TCP and RTSP, but also for TLS. This may
increase the vulnerability to DoS attacks.</t>
<t>In addition to these recommendations, <xref
target="sec_sec-frame-proxy"></xref> gives further recommendations of
TLS usage with proxies.</t>
</section>
<section anchor="sec_sec-frame-proxy" title="Security and Proxies">
<t>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-middle". This section provides clients with the
possibility to use proxies even when applying secure transports (TLS)
between the RTSP agents. The TLS proxy mechanism allows for server and
proxy identification using certificates. However, the client can not
be identified based on certificates. The client needs to select
between using the procedure specified below or using a TLS connection
directly (by-passing any proxies) to the server. The choice may be
dependent on policies.</t>
<t>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 aware). An infrastructure based on
proxies requires that the trust model is such that both client and
servers 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 of the proxy. Hence, transparent proxies cannot generally be
seen as trusted and will not work well with security (unless they work
only at transport layer). In the rest of this section any reference to
proxy will be to a non-transparent proxy, which inspects or manipulate
the RTSP messages.</t>
<t>HTTP Authentication is built on the assumption of proxies and can
provide user-proxy authentication and proxy-proxy/server
authentication in addition to the client-server authentication.</t>
<t>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
that for TLS, the client will authenticate the proxy server and not
the end server. Note that when the client checks the server
certificate in TLS, it MUST check the proxy's identity (URI or
possibly other known identity) against the proxy's identity as
presented in the proxy's Certificate message.</t>
<t>The problem is that for a proxy accepted by the client, the proxy
needs to be provided information on which grounds it should accept 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
behavior. To handle this case, the Accept-Credentials header (See
<xref target="sec_Accept-Credentials"></xref>) is used, where the
client can force the proxy/proxies to relay back the chain of
certificates used to authenticate any intermediate proxies as well as
the server. Given the assumption that the proxies are viewed as
trusted, it gives the user a possibility to enforce policies to each
trusted proxy of whether it should accept the next entity in the
chain.</t>
<t>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
client and proxy, or between proxy and proxy), even if the resource
and the end server does not require to use it. The proxy SHALL when
initiating the next hop TLS connection use the incomming TLS
connections CipherSuite list, only modified by removing any cipher
suits that the proxy does not support. In case a proxy fails to
establish a TLS connection due to cipher suite mismatch between proxy
and next hop proxy or server, this is indicated using error code 472
(Failure to establish secure connection).</t>
<section anchor="sec-frame-accept-cred" title="Accept-Credentials">
<t>The Accept-Credentials header can be used by the client to
distribute simple authorization policies to intermediate proxies.
The client includes the Accept-Credentials header to dictate how the
proxy treats the server/next proxy certificate. There are currently
three methods defined: <list hangIndent="6" style="hanging">
<t hangText="Any,">which means that the proxy (or proxies) SHALL
accept whatever certificate presented. This is of course not a
recommended option to use, but may be useful in certain
circumstances (such as testing).</t>
<t hangText="Proxy,">which means that the proxy (or proxies)
MUST use its own policies to validate the certificate and decide
whether to accept it or not. This is convenient in cases where
the user has a strong trust relation with the proxy. Reason why
a strong trust relation may exist are; personal/company proxy,
proxy has a out-of-band policy configuration mechanism.</t>
<t hangText="User,">which means that the proxy (or proxies) MUST
send credential information about the next hop to the client for
authorization. The client can then decide whether the proxy
should accept the certificate or not. See <xref
target="sec_security-tls-proxy"></xref> for further details.</t>
</list></t>
<t>If the Accept-Credentials header is not included in the RTSP
request from the client, then the "Proxy" method SHALL be used as
default. If an other method than the "Proxy" is to be used, then the
Accept-Credentials header SHALL be included in all of the RTSP
request from the client. This is because it cannot be assumed that
the proxy always keeps the TLS state or the users previously
preference between different RTSP messages (in particular if the
time interval between the messages is long).</t>
<t>With the "Any" and "Proxy" methods the proxy will apply the
policy as defined for respectively method. If the policy do not
accept the credentials of the next hop, the entity SHALL respond
with a message using status code 471 (Connection Credentials not
accepted).</t>
<t>An RTSP request in the direction server to client MUST NOT
include the Accept-Credential header. As for the non-secured
communication, the possibility for these request depends on the
presence of a client established connection. However if the server
to client request is in relation to a session established over a TLS
secured channel, if MUST be sent in a TLS secured connection. That
secured 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 server desire to send the request, it silently fails.</t>
<t>Further policies MAY be defined and registered, but should be
done so with caution.</t>
</section>
<section anchor="sec_security-tls-proxy"
title="User approved TLS procedure">
<t>For the "User" method each proxy MUST perform the the following
procedure for each RTSP request: <list hangIndent="3"
style="symbols">
<t>Setup the TLS session to the next hop if not already present
(i.e. run the TLS handshake, but do not send the RTSP
request).</t>
<t>Extract the peer certificate chain for the TLS session.</t>
<t>Check if a matching identity and hash of the peer certificate
is present in the Accept-Credentials header. If present, send
the message to the next hop, and conclude these procedures. If
not, go to the next step.</t>
<t>The proxy responds to the RTSP request with a 470 or 407
response code. The 407 response code MAY be used when the proxy
requires both user and connection authorization from user or
client. In this message the proxy SHALL include a
Connection-Credentials header, see <xref
target="sec_Connection-Credentials"></xref> with the next hop's
identity and certificate.</t>
</list></t>
<t>The client MUST upon receiving a 470 or 407 response with
Connection-Credentials header take the decision on whether to accept
the certificate or not (if it cannot do so, the user SHOULD be
consulted). If the certificate is accepted, the client has to again
send the RTSP request. In that request the client has to include the
Accept-Credentials header including the hash over the DER encoded
certificate for all trusted proxies in the chain.</t>
<t>Example: <figure>
<artwork><![CDATA[
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Accept-Ranges: NPT, SMPTE, UTC
Accept-Credentials: User]]></artwork>
</figure><figure>
<artwork><![CDATA[P->C: RTSP/2.0 470 Connection Authorization Required
CSeq: 2
Connection-Credentials: "rtsps://test.example.org";
MIIDNTCCAp...
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: NPT, SMPTE, UTC]]></artwork>
</figure><figure>
<artwork><![CDATA[P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Via: RTSP/2.0 proxy.example.org
Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: NPT, SMPTE, UTC]]></artwork>
</figure></t>
<t>One implication of this process is that the connection for
secured RTSP messages may take significantly more round-trip times
for the first message. An complete extra message exchange between
the proxy connecting to the next hop and the client results because
of the process for approval for each hop. However after the first
message exchange the remaining message should not be delayed, if
each message contains the chain of proxies that the requestor
accepts. The procedure of including the credentials in each request
rather than building state in each proxy, avoids the need for
revocation procedures.</t>
</section>
</section>
</section>
<!-- title="Security Framework" -->
<section anchor="sec_syntax" title="Syntax">
<t>The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF)
as defined in RFC 5234 <xref target="RFC5234"></xref>. It uses the basic
definitions present in RFC 5234.</t>
<t>Please note that ABNF strings, e.g. "Accept", are case insensitive as
specified in section 2.3 of RFC 5234.</t>
<section title="Base Syntax">
<t>RTSP header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream.
This is intended to behave exactly as HTTP/1.1 as described in RFC
2616 <xref target="RFC2616"></xref>. The SWS construct is used when
linear white space is optional, generally between tokens and
separators.</t>
<t>To separate the header name from the rest of value, a colon is
used, which, by the above rule, allows whitespace before, but no line
break, and whitespace after, including a linebreak. The HCOLON defines
this construct. <figure>
<artwork><![CDATA[
OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z"
LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z"
ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control charac7ter
; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13
LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9)
DQ = %x22 ; US-ASCII double-quote mark (34)
BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF]]></artwork>
</figure> <figure>
<artwork><![CDATA[
LWS = [CRLF] 1*( SP / HT )
SWS = [LWS] ; sep whitespace
HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQ
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQ *qdtext DQ )
qdtext = %x20-21 / %x23-7E / %x80-FF ; any TEXT except <">
quoted-pair = BACKSLASH CHAR
ctext = %x20-27 / %x2A-7E
/ %x80-FF ; any OCTET except CTLs, "(" and ")"
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string]]></artwork>
</figure> <figure>
<artwork><![CDATA[
safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra = "!" / "*" / "'" / "(" / ")"
HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
LHEX = DIGIT / %x61-66 ;lowercase a-f
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
unreserved = ALPHA / DIGIT / safe / extra
rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = (2base64-char "==") / (3base64-char "=")
base64-char = ALPHA / DIGIT / "+" / "/"]]></artwork>
</figure> <figure>
<artwork><![CDATA[
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
LDQUOT = SWS DQ ; open double quotation mark
RDQUOT = DQ SWS ; close double quotation mark
RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
FLOAT = ["-"] 1*39DIGIT ["." 1*46DIGIT]
POS-FLOAT = 1*39DIGIT ["." 1*46DIGIT]]]></artwork>
</figure></t>
</section>
<section anchor="sec_syntax-prot" title="RTSP Protocol Definition">
<section anchor="sec_syntax-prot-generic"
title="Generic Protocol elements">
<t><figure>
<artwork><![CDATA[
RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ]
ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-noscheme
/ ipath-empty
iauthority = < As defined in RFC 3987>
ipath = ipath-abempty ; begins with "/" or is empty
/ ipath-absolute ; begins with "/" but not "//"
/ ipath-noscheme ; begins with a non-colon segment
/ ipath-rootless ; begins with a segment
/ ipath-empty ; zero characters
ipath-abempty = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar>
isegment = *ipchar [";" *ipchar]
isegment-nz = 1*ipchar [";" *ipchar]
/ ";" *ipchar
isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc])
/ ";" *ipchar-nc
; non-zero-length segment without any colon ":"
ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@"
ipchar-nc = iunreserved / pct-encoded / sub-delims / "@"
iquery = < As defined in RFC 3987>
ifragment = < As defined in RFC 3987>
iunreserved = < As defined in RFC 3987>
pct-encoded = < As defined in RFC 3987>]]></artwork>
</figure></t>
<t><figure>
<artwork><![CDATA[
RTSP-URI = schemes ":" URI-rest
RTSP-URI-Ref = RTSP-URI / RTSP-Relative
schemes = "rtsp" / "rtsps" / scheme
scheme = < As defined in RFC 3986>
URI-rest = hier-part [ "?" query ]
hier-part = "//" authority path-abempty
RTSP-Relative = relative-part [ "?" query ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
authority = < As defined in RFC 3986>
query = < As defined in RFC 3986>
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
segment = *pchar [";" *pchar]
segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar)
segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc)
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc = unreserved / pct-encoded / sub-delims / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / "="
]]></artwork>
</figure> <figure>
<artwork><![CDATA[
smpte-range = smpte-type "=" smpte-range-spec
; See section 3.4
smpte-range-spec = ( smpte-time "-" [ smpte-time ] )
/ ( "-" smpte-time )
smpte-type = "smpte" / "smpte-30-drop"
/ "smpte-25" / smpte-type-extension
; other timecodes may be added
smpte-type-extension = token
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT
[ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]
]]></artwork>
</figure> <figure>
<artwork><![CDATA[
npt-range = "npt=" npt-range-spec
npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time = "now" / npt-sec / npt-hhmmss
npt-sec = 1*DIGIT [ "." *DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
npt-hh = 1*DIGIT ; any positive number
npt-mm = 1*2DIGIT ; 0-59
npt-ss = 1*2DIGIT ; 0-59
]]></artwork>
</figure> <figure>
<artwork><![CDATA[
utc-range = "clock=" utc-range-spec
utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time = utc-date "T" utc-clock "Z"
utc-date = 8DIGIT
utc-clock = 6DIGIT [ "." fraction ]
fraction = 1*DIGIT
]]></artwork>
</figure> <figure>
<artwork><![CDATA[
feature-tag = token
session-id = 1*256( ALPHA / DIGIT / safe )
extension-header = header-name HCOLON header-value
header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
]]></artwork>
</figure></t>
</section>
<section anchor="sec_syntax-prot-message" title="Message Syntax">
<t><figure>
<artwork><![CDATA[
RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line
*((general-header
/ request-header
/ entity-header) CRLF)
CRLF
[ message-body ]
Response = Status-Line
*((general-header
/ response-header
/ entity-header) CRLF)
CRLF
[ message-body ] ]]></artwork>
</figure> <figure>
<artwork><![CDATA[
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF]]></artwork>
</figure> <figure>
<artwork><![CDATA[Method = "DESCRIBE"
/ "GET_PARAMETER"
/ "OPTIONS"
/ "PAUSE"
/ "PLAY"
/ "PLAY_NOTIFY"
/ "REDIRECT"
/ "SETUP"
/ "SET_PARAMETER"
/ "TEARDOWN"
/ extension-method
extension-method = token]]></artwork>
</figure> <figure>
<artwork><![CDATA[
Request-URI = "*" / RTSP-URI
RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT
message-body = 1*OCTET]]></artwork>
</figure> <figure>
<artwork><![CDATA[
Status-Code = "100" ; Continue
/ "200" ; OK
/ "300" ; Multiple Choices
/ "301" ; Moved Permanently
/ "302" ; Found
/ "303" ; See Other
/ "304" ; Not Modified
/ "305" ; Use Proxy
/ "400" ; Bad Request
/ "401" ; Unauthorized
/ "402" ; Payment Required
/ "403" ; Forbidden
/ "404" ; Not Found
/ "405" ; Method Not Allowed
/ "406" ; Not Acceptable
/ "407" ; Proxy Authentication Required
/ "408" ; Request Time-out
/ "410" ; Gone
/ "411" ; Length Required
/ "412" ; Precondition Failed
/ "413" ; Request Entity Too Large
/ "414" ; Request-URI Too Large
/ "415" ; Unsupported Media Type
/ "451" ; Parameter Not Understood
/ "452" ; reserved
/ "453" ; Not Enough Bandwidth
/ "454" ; Session Not Found
/ "455" ; Method Not Valid in This State
/ "456" ; Header Field Not Valid for Resource
/ "457" ; Invalid Range
/ "458" ; Parameter Is Read-Only
/ "459" ; Aggregate operation not allowed
/ "460" ; Only aggregate operation allowed
/ "461" ; Unsupported Transport
/ "462" ; Destination Unreachable
/ "463" ; Destination Prohibited
/ "464" ; Data Transport Not Ready Yet
/ "470" ; Connection Authorization Required
/ "471" ; Connection Credentials not accepted
/ "472" ; Failure to establish secure connection
/ "500" ; Internal Server Error
/ "501" ; Not Implemented
/ "502" ; Bad Gateway
/ "503" ; Service Unavailable
/ "504" ; Gateway Time-out
/ "505" ; RTSP Version not supported
/ "551" ; Option not supported
/ extension-code
extension-code = 3DIGIT
Reason-Phrase = *TEXT]]></artwork>
</figure> <figure>
<artwork><![CDATA[
general-header = Cache-Control
/ Connection
/ CSeq
/ Date
/ Media-Properties
/ Media-Range]]></artwork>
</figure><figure>
<artwork><![CDATA[ / Pipelined-Requests
/ Proxy-Supported
/ Seek-Style
/ Supported
/ Timestamp
/ Via
/ extension-header]]></artwork>
</figure> <figure>
<artwork><![CDATA[
request-header = Accept
/ Accept-Credentials
/ Accept-Encoding
/ Accept-Language
/ Authorization
/ Bandwidth
/ Blocksize
/ From
/ If-Match
/ If-Modified-Since
/ If-None-Match]]></artwork>
</figure><figure>
<artwork><![CDATA[ / Notify-Reason
/ Proxy-Require
/ Range
/ Referer
/ Request-Status
/ Require
/ Scale
/ Session
/ Speed
/ Supported
/ Transport
/ User-Agent
/ extension-header ]]></artwork>
</figure> <figure>
<artwork><![CDATA[
response-header = Accept-Credentials
/ Accept-Ranges
/ Connection-Credentials
/ ETag
/ Location
/ Proxy-Authenticate
/ Public
/ Range
/ Retry-After
/ RTP-Info
/ Scale
/ Session
/ Server
/ Speed
/ Transport
/ Unsupported
/ Vary
/ WWW-Authenticate
/ extension-header]]></artwork>
</figure> <figure>
<artwork><![CDATA[
entity-header = Allow
/ Content-Base
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Location
/ Content-Type
/ Expires
/ Last-Modified
/ extension-header]]></artwork>
</figure></t>
</section>
<section anchor="sec_syntax-prot-header" title="Header Syntax">
<t>All header syntaxes not defined in this section are defined in
section 14 of the HTTP 1.1 specification <xref
target="RFC2616"></xref>. <figure>
<artwork><![CDATA[
Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ]
accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*"
/ ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype )
) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info])
/ "Proxy"
/ "Any"
/ token [LWS 1*TEXT] ; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64
hash-alg = "sha-256" / extension-alg
extension-alg = token
Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param)
codings = content-coding / "*"
content-coding = token
Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ]
language = language-range *(SEMI accept-param)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges
acceptable-ranges = (range-unit *(COMMA range-unit))
/ "none"
range-unit = "NPT" / "SMPTE" / "UTC" / extension-format
extension-format = token
Allow = "Allow" HCOLON [Method *(COMMA Method)]
Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response)
/ other-response
digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce
/ opaque / message-qop
/ nonce-count / auth-param
username = "username" EQUAL username-value
username-value = quoted-string
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value = Request-URI
; by HTTP/1.1
message-qop = "qop" EQUAL qop-value
cnonce = "cnonce" EQUAL cnonce-value
cnonce-value = nonce-value
nonce-count = "nc" EQUAL nc-value
nc-value = 8LHEX
dresponse = "response" EQUAL request-digest
request-digest = LDQUOT 32LHEX RDQUOT
auth-param = auth-param-name EQUAL
( token / quoted-string )
auth-param-name = token
other-response = auth-scheme LWS auth-param
*(COMMA auth-param)
auth-scheme = token
Bandwidth = "Bandwidth" HCOLON 1*DIGIT
Blocksize = "Blocksize" HCOLON 1*DIGIT ]]></artwork>
</figure><figure>
<artwork><![CDATA[
Cache-Control = "Cache-Control" HCOLON cache-directive
*(COMMA cache-directive)
cache-directive = cache-rqst-directive
/ cache-rspns-directive
cache-rqst-directive = "no-cache"
/ "max-stale" [EQUAL delta-seconds]
/ "min-fresh" EQUAL delta-seconds
/ "only-if-cached"
/ cache-extension
cache-rspns-directive = "public"
/ "private"
/ "no-cache"
/ "no-transform"
/ "must-revalidate"
/ "proxy-revalidate"
/ "max-age" EQUAL delta-seconds
/ cache-extension
cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*DIGIT]]></artwork>
</figure> <figure>
<artwork><![CDATA[
Connection-Credentials = "Connection-Credentials" HCOLON cred-chain ]]></artwork>
</figure></t>
<t><figure>
<artwork><![CDATA[cred-chain = DQ RTSP-URI DQ SEMI base64
Connection = "Connection" HCOLON (connection-token)
*(COMMA connection-token)
connection-token = token
Content-Base = "Content-Base" HCOLON RTSP-URI-Ref
Content-Encoding = "Content-Encoding" HCOLON
content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag)
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Content-Length = "Content-Length" HCOLON 1*DIGIT
Content-Location = "Content-Location" HCOLON RTSP-URI-Ref
Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
m-subtype = extension-token / iana-token
iana-token = token
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
CSeq = "Cseq" HCOLON cseq-nr
cseq-nr = 1*9DIGIT
Date = "Date" HCOLON RTSP-date
RTSP-date = rfc1123-date ; HTTP-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" / "Tue" / "Wed"
/ "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec"
ETag = "ETag" HCOLON entity-tag
Expires = "Expires" HCOLON delta-seconds
From = "From" HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = RTSP-URI / absolute-URI
absolute-URI = < As defined in RFC 3986>
display-name = *(token LWS)/ quoted-string
from-param = tag-param / generic-param
tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ( "*" / entity-tag-list)
entity-tag-list = entity-tag *(COMMA entity-tag)
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date
If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list)
Last-Modified = "Last-Modified" HCOLON RTSP-date
Location = "Location" HCOLON RTSP-URI
Media-Properties = "Media-Properties" HCOLON media-prop-list
media-prop-list = media-prop-value *(COMMA media-prop-value)
media-prop-value = "Random-Access" EQUAL POS-FLOAT
/ "Begining-Only"
/ "No-Seeking"
/ "Unmutable"
/ "Dynamic"
/ "Time-Progressing"
/ "Unlimited"
/ "Time-Limited" EQUAL utc-range-spec
/ "Time-Duration" EQUAL POS-FLOAT
/ media-prop-ext
media-prop-ext = token [EQUAL SWS 1*rtsp-unreserved / quoted-string]
Media-Range = "Media-Range" HCOLON [ranges-list]
Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val = "end-of-stream"
/ "media-properties-update"
/ "scale-change"
/ Notify-Reason-extension
Notify-Reason-extension = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id = 1*8DIGIT]]></artwork>
</figure></t>
<t><figure>
<artwork><![CDATA[Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ other-challenge
other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param)
digest-cln = realm / domain / nonce
/ opaque / stale / algorithm
/ qop-options / auth-param
realm = "realm" EQUAL realm-value
realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI
*( 1*SP URI ) RDQUOT
URI = RTSP-URI / RTSP-URI-Ref
nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token)
qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token
Proxy-Require = "Proxy-Require" HCOLON feature-tag
*(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON feature-tag
*(COMMA feature-tag)
Public = "Public" HCOLON Method *(COMMA Method)
Range = "Range" HCOLON ranges-list [exec-time]
ranges-list = ranges-spec *(COMMA ranges-spec)
exec-time = SEMI "time" EQUAL utc-time
ranges-spec = npt-range / utc-range / smpte-range
/ range-ext
range-ext = extension-format "=" range-value
range-value = 1*(rtsp-unreserved / quoted-string / ":" )
Referer = "Referer" HCOLON RTSP-URI-Ref
Request-Status = "Request-Status" HCOLON status-info
status-info = cseq-info LWS status-info LWS reason-info
cseq-info = "cseq" EQUAL cseq-nr
status-info = "status" EQUAL Status-Code
reason-info = "reason" EQUAL DQ Reason-Phrase DQ
Require = "Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag)]]></artwork>
</figure><figure>
<artwork><![CDATA[RTP-Info = "RTP-Info" HCOLON rtsp-info-spec
*(COMMA rtsp-info-spec)
rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter)
ri-parameter = "seq" EQUAL 1*DIGIT
/ "rtptime" EQUAL 1*DIGIT
Retry-After = "Retry-After" HCOLON delta-seconds
[ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds)
/ generic-param]]></artwork>
</figure><figure>
<artwork><![CDATA[
Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ]
Seek-Style = "Seek-Style" HCOLON Seek-S-values
Seek-S-values = "RAP"
/ "First-Prior"
/ "Next"
/ Seek-S-value-ext
Seek-S-value-ext = token
Speed = "Speed" HCOLON 1*DIGIT [ "." *DIGIT ]
Server = "Server" HCOLON ( product / comment )
*(LWS (product / comment))
product = token [SLASH product-version]
product-version = token
comment = LPAREN *( ctext / quoted-pair) RPAREN
Session = "Session" HCOLON session-id
[ SEMI "timeout" EQUAL delta-seconds ]
Supported = "Supported" HCOLON [feature-tag-list]
]]></artwork>
</figure> <figure>
<artwork><![CDATA[
Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay]
timestamp-value = *DIGIT [ "." *DIGIT ]
delay = *DIGIT [ "." *DIGIT ]
Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec)
transport-spec = transport-id *tr-parameter
transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id
other-trans = token *("/" token)]]></artwork>
</figure> <figure>
<artwork><![CDATA[
profile = "AVP" / "SAVP" / "AVPF" / token
lower-transport = "TCP" / "UDP" / token
tr-parameter = SEMI ( "unicast" / "multicast" )
/ SEMI "interleaved" EQUAL channel [ "-" channel ]
/ SEMI "append"
/ SEMI "ttl" EQUAL ttl
/ SEMI "layers" EQUAL 1*DIGIT
/ SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)
/ SEMI "client_ssrc" EQUAL ssrc
/ SEMI "mode" EQUAL mode-spec
/ SEMI "dest_addr" EQUAL addr-list
/ SEMI "src_addr" EQUAL addr-list
/ SEMI trn-param-ext
/ SEMI "setup" EQUAL contrans-setup
/ SEMI "connection" EQUAL contrans-con
contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing"
trn-param-ext = par-name [EQUAL trn-par-value]
par-name = token
trn-par-value = *(rtsp-unreserved / DQ *TEXT DQ)
ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX
channel = 1*3DIGIT
mode-spec = ( DQ mode *(COMMA mode) DQ )
mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQ (host-port / extension-addr) DQ
host-port = host [":" port]
/ ":" port
extension-addr = 1*qdtext
host = < As defined in RFC 3986>
port = < As defined in RFC 3986>
]]></artwork>
</figure> <figure>
<artwork><![CDATA[
Unsupported = "Unsupported" HCOLON feature-tag-list
User-Agent = "User-Agent" HCOLON ( product / comment )
0*(LWS (product / comment))
Vary = "Vary" HCOLON ( "*" / field-name-list)
field-name-list = field-name *(COMMA field-name)
field-name = token
Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ via-extension
via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address)
IPv4address = < As defined in RFC 3986>
IPv6address = < As defined in RFC 3986>
via-branch = "branch" EQUAL token
via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot
protocol-name = "RTSP" / token
protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token
sent-by = host [ COLON port ]
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="sec_sdp-syntax" title="SDP extension Syntax">
<t>This section defines in ABNF the SDP extensions defined for RTSP.
See <xref target="sec_sdpusage"></xref> for the definition of the
extensions in text. <figure>
<artwork><![CDATA[
control-attribute = "a=control:" *SP RTSP-URI
a-range-def = "a=range:" ranges-spec CRLF
a-etag-def = "a=etag:" entity-tag CRLF
]]></artwork>
</figure></t>
</section>
</section>
<!-- title="Syntax" -->
<section anchor="sec_security" title="Security Considerations">
<t>Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security considerations outlined in [H15] apply.
Specifically, please note the following: <list hangIndent="6"
style="hanging">
<t hangText="Abuse of Server Log Information:">RTSP and HTTP servers
will presumably have similar logging mechanisms, and thus should be
equally guarded in protecting the contents of those logs, thus
protecting the privacy of the users of the servers. See [H15.1.1]
for HTTP server recommendations regarding server logs.</t>
<t hangText="Transfer of Sensitive Information:">There is no reason
to believe that information transferred or controlled via RTSP may
be any less sensitive than that normally transmitted via HTTP.
Therefore, all of the precautions regarding the protection of data
privacy and user privacy apply to implementors of RTSP clients,
servers, and proxies. See [H15.1.2] for further details.</t>
<t hangText="Attacks Based On File and Path Names:">Though RTSP URIs
are opaque handles that do not necessarily have file system
semantics, it is anticipated that many implementations will
translate portions of the Request-URIs directly to file system
calls. In such cases, file systems SHOULD follow the precautions
outlined in [H15.5], such as checking for ".." in path
components.</t>
<t hangText="Personal Information:">RTSP clients are often privy to
the same information that HTTP clients are (user name, location,
etc.) and thus should be equally sensitive. See [H15.1] for further
recommendations.</t>
<t hangText="Privacy Issues Connected to Accept Headers:">Since may
of the same "Accept" headers exist in RTSP as in HTTP, the same
caveats outlined in [H15.1.4] with regards to their use should be
followed.</t>
<t hangText="DNS Spoofing:">Presumably, given the longer connection
times typically associated to RTSP sessions relative to HTTP
sessions, RTSP client DNS optimizations should be less prevalent.
Nonetheless, the recommendations provided in [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 the mapping.</t>
<t hangText="Location Headers and Spoofing:">If a single server
supports multiple organizations that do not trust each another, then
it needs to check the values of Location and Content-Location header
fields in responses that are generated under control of said
organizations to make sure that they do not attempt to invalidate
resources over which they have no authority. ([H15.4])</t>
</list></t>
<t>In addition to the recommendations in the current HTTP specification
(RFC 2616 <xref target="RFC2616"></xref>, as of this writing) and also
of the previous RFC2068 <xref target="RFC2068"></xref>, future HTTP
specifications may provide additional guidance on security issues.</t>
<t>The following are added considerations for RTSP implementations.
<list hangIndent="6" style="hanging">
<t hangText="Concentrated denial-of-service attack:">The protocol
offers the opportunity for a remote-controlled denial-of-service
attack. See <xref target="sec-dos"></xref>.</t>
<t hangText="Session hijacking:">Since there is no or little
relation between a transport layer connection and an RTSP session,
it is possible for a malicious client to issue requests with random
session identifiers which would affect unsuspecting clients. The
server SHOULD use a large, random and non-sequential session
identifier to minimize the possibility of this kind of attack.
However, unless the RTSP signalling always are confedentiality
protected, e.g. using TLS, an on-path attacker will be able to
hijack a session. For real session security, client authentication
needs to be performed.</t>
<t hangText="Authentication:">Servers SHOULD implement both basic
and digest <xref target="RFC2617"></xref> authentication. In
environments requiring tighter security for the control messages,
the transport layer mechanism TLS (RFC 4346 <xref
target="RFC4346"></xref>) SHOULD be used.</t>
<t hangText="Stream issues:">RTSP only provides for stream control.
Stream delivery issues are not covered in this section, nor in the
rest of this draft. RTSP implementations will most likely rely on
other protocols such as RTP, IP multicast, RSVP and IGMP, and should
address security considerations brought up in those and other
applicable specifications.</t>
<t hangText="Persistently suspicious behavior:">RTSP servers SHOULD
return error code 403 (Forbidden) upon receiving a single instance
of behavior which is deemed a security risk. RTSP servers SHOULD
also be aware of attempts to probe the server for weaknesses and
entry points and MAY arbitrarily disconnect and ignore further
requests clients which are deemed to be in violation of local
security policy.</t>
<t hangText="Scope of Multicast:">If RTSP is used to control the
transmission of media onto a multicast network it is need to
consider the scope that delivery has. RTSP supports the TTL
Transport header parameter to indicate this scope. However such
scope control is risk as it may be set to large and distribute media
beyond the intended scope.</t>
<t hangText="TLS through proxies:">If one uses the possibility to
connect TLS in multiple legs (<xref
target="sec_sec-frame-proxy"></xref> one really needs to be aware of
the trust model. That procedure requires full faith and trust in all
proxies that one allows to connect through. They are man in the
middle and has access to all that goes on over the TLS connection.
Thus it is important to consider if that trust model is acceptable
in the actual application.</t>
</list></t>
<section anchor="sec-dos" title="Remote denial of Service Attack">
<t>The attacker may initiate traffic flows to one or more IP addresses
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
useful in prevention of more attacks or ascertaining the attackers
identity. Thus, an RTSP server MUST only allow client-specified
destinations for RTSP-initiated traffic flows if the server has
ensured that the specified destination address accepts receiving media
through different security mechanisms. Security mechanism that are
acceptable in an increased generality are; verification of the
client's identity, either against a database of known users using RTSP
authentication mechanisms (preferably digest authentication or
stronger); a list of addresses that accept to be media destinations,
especially considering user identity; and media path based
verification.</t>
<t>The server SHOULD NOT allow the destination field to be set unless
a mechanism exists in the system to authorize the request originator
to direct streams to the recipient. It is preferred that this
authorization be performed by the media recipient (destination) itself
and the credentials passed along to the server. However, in certain
cases, such as when recipient address is a multicast group, or when
the recipient is unable to communicate with the server in an
out-of-band manner, this may not be possible. In these cases server
may chose another method such as a server-resident authorization list
to ensure that the request originator has the proper credentials to
request stream delivery to the recipient.</t>
<t>One solution that performs the necessary verification of acceptance
of media suitable for unicast based delivery is the ICE based NAT
traversal method described in <xref
target="I-D.ietf-mmusic-rtsp-nat"></xref>. By using random passwords
and username the probability of unintended indication as a valid media
destination is very low. If the server include in its STUN requests a
cookie (consisting of random material) that is the destination echo
back the solution is also safe against having a off-path attacker
being able to spoof the STUN checks. Leaving this solution vulnerable
only to on-path attackers that can see the STUN requests go to the
target of attack.</t>
<t>For delivery to multicast addresses there is need for another
solution which is not specified here.</t>
</section>
</section>
<!-- title="Security Considerations" -->
<section anchor="sec_IANA" title="IANA Considerations">
<t>This section sets up a number of registries for RTSP 2.0 that should
be maintained by IANA. For each registry there is a description on what
it is required to contain, what specification is needed when adding a
entry with IANA, and finally the entries that this document needs to
register. See also the <xref target="sec_extend-rtsp"></xref> "Extending
RTSP". There is also an IANA registration of two SDP attributes.</t>
<t>The sections describing how to register an item uses some of the
requirements level described in RFC YYYY <xref
target="I-D.narten-iana-considerations-rfc2434bis"></xref>, namely
"First Come, First Served", "Expert Review, "Specification Required",
and "Standards Action".</t>
<t>A registration request to IANA MUST contain the following
information: <list hangIndent="3" style="symbols">
<t>A name of the item to register according to the rules specified
by the intended registry.</t>
<t>Indication of who has change control over the feature (for
example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium, a particular company or group of companies, or
an individual);</t>
<t>A reference to a further description, if available, for example
(in decreasing order of preference) an RFC, a published standard, a
published paper, a patent filing, a technical report, documented
source code or a computer manual;</t>
<t>For proprietary features, contact information (postal and email
address);</t>
</list></t>
<section title="Feature-tags">
<section title="Description">
<t>When a client and server try to determine what part and
functionality of the RTSP specification and any future extensions
that its counter part implements there is need for a namespace. This
registry contains named entries representing certain
functionality.</t>
<t>The usage of feature-tags is explained in <xref
target="sec_capability"></xref> and <xref
target="sec_OPTIONS"></xref>.</t>
</section>
<section title="Registering New Feature-tags with IANA">
<t>The registering of feature-tags is done on a first come, first
served basis.</t>
<t>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 name MUST NOT contain any spaces, or control characters. The
registration SHALL indicate if the feature-tag applies to clients,
servers, or proxies only or any combinations of these. Any
proprietary feature SHALL have as the first part of the name a
vendor tag, which identifies the organization.</t>
</section>
<section title="Registered entries">
<t>The following feature-tags are in this specification defined and
hereby registered. The change control belongs to the IETF. <list
hangIndent="6" style="hanging">
<t hangText="play.basic:">The minimal implementation for
playback operations according to this specification. Applies for
both clients, servers and proxies.</t>
<t hangText="play.scale:">Support of scale operations for media
playback. Applies only for servers.</t>
<t hangText="play.speed:">Support of the speed functionality for
playback. Applies only for servers.</t>
</list></t>
</section>
</section>
<section title="RTSP Methods">
<section title="Description">
<t>What a method is, is described in section <xref
target="sec_methods"></xref>. Extending the protocol with new
methods allow for totally new functionality.</t>
</section>
<section title="Registering New Methods with IANA">
<t>A new method MUST be registered through an IETF Standards Action.
The reason is that new methods may radically change the protocols
behavior and purpose.</t>
<t>A specification for a new RTSP method MUST consist of the
following items: <list hangIndent="3" style="symbols">
<t>A method name which follows the ABNF rules for methods.</t>
<t>A clear specification on what action and response a request
with the method will result in. Which directions the method is
used, C->S or S->C or both. How the use of headers, if
any, modifies the behavior and effect of the method.</t>
<t>A list or table specifying which of the registered headers
that are allowed to use with the method in request or/and
response.</t>
<t>Describe how the method relates to network proxies.</t>
</list></t>
</section>
<section title="Registered Entries">
<t>This specification, RFCXXXX, registers 10 methods: DESCRIBE,
GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY REDIRECT, SETUP,
SET_PARAMETER, and TEARDOWN.</t>
</section>
</section>
<section title="RTSP Status Codes">
<section title="Description">
<t>A status code is the three digit numbers used to convey
information in RTSP response messages, see<xref
target="sec_response"></xref>. The number space is limited and care
should be taken not to fill the space.</t>
</section>
<section title="Registering New Status Codes with IANA">
<t>A new status code can only be registered by an IETF Standards
Action. A specification for a new status code MUST specify the
following: <list hangIndent="3" style="symbols">
<t>The requested number.</t>
<t>A description what the status code means and the expected
behavior of the sender and receiver of the code.</t>
</list></t>
</section>
<section title="Registered Entries">
<t>RFCXXX, registers the numbered status code defined in the ABNF
entry "Status-Code" except "extension-code" in <xref
target="sec_syntax-prot-message"></xref>.</t>
</section>
</section>
<section title="RTSP Headers">
<section title="Description">
<t>By specifying new headers a method(s) can be enhanced in many
different ways. An unknown header will be ignored by the receiving
entity. If the new header is vital for a certain functionality, a
feature-tag for the functionality can be created and demanded to be
used by the counter-part with the inclusion of a Require header
carrying the feature-tag.</t>
</section>
<section title="Registering New Headers with IANA">
<t>Registrations in the registry can be done following the Expert
Review policy. A specification SHOULD be provided, preferable an
IETF RFC or other Standards Developing Organization specification.
The minimal information in a registration request is the header name
and the contact information.</t>
<t>The specification SHOULD contain the following information: <list
hangIndent="3" style="symbols">
<t>The name of the header.</t>
<t>An ABNF specification of the header syntax.</t>
<t>A list or table specifying when the header may be used,
encompassing all methods, their request or response, the
direction (C->S or S->C).</t>
<t>How the header is to be handled by proxies.</t>
<t>A description of the purpose of the header.</t>
</list></t>
</section>
<section title="Registered entries">
<t>All headers specified in <xref target="sec_headers"></xref> in
RFCXXXX are to be registered.</t>
<t>Furthermore the following RTSP headers defined in other
specifications are registered: <list hangIndent="3" style="symbols">
<t>x-wap-profile defined in <xref
target="3gpp-26234"></xref>.</t>
<t>x-wap-profile-diff defined in <xref
target="3gpp-26234"></xref>.</t>
<t>x-wap-profile-warning defined in <xref
target="3gpp-26234"></xref>.</t>
<t>x-predecbufsize defined in <xref
target="3gpp-26234"></xref>.</t>
<t>x-initpredecbufperiod defined in <xref
target="3gpp-26234"></xref>.</t>
<t>x-initpostdecbufperiod defined in <xref
target="3gpp-26234"></xref>.</t>
<t>3gpp-videopostdecbufsize defined in <xref
target="3gpp-26234"></xref>.</t>
<t>3GPP-Link-Char defined in <xref
target="3gpp-26234"></xref>.</t>
<t>3GPP-Adaptation defined in <xref
target="3gpp-26234"></xref>.</t>
<t>3GPP-QoE-Metrics defined in <xref
target="3gpp-26234"></xref>.</t>
<t>3GPP-QoE-Feedback defined in <xref
target="3gpp-26234"></xref>.</t>
</list></t>
<t>The use of "x-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification.</t>
</section>
</section>
<section anchor="sec_IANA-trn" title="Transport Header Registries">
<t>The transport header contains a number of parameters which have
possibilities for future extensions. Therefore registries for these
needs to be defined.</t>
<section title="Transport Protocol Specification">
<t>A registry for the parameter transport-protocol specification
SHALL be defined with the following rules: <list hangIndent="3"
style="symbols">
<t>Registering uses the policy of Specification Required.</t>
<t>A contact person or organization with address and email.</t>
<t>A value definition that are following the ABNF syntax
definition.</t>
<t>A describing text that explains how the registered value are
used in RTSP.</t>
</list></t>
<t>This specification registers the following values: <list
hangIndent="6" style="hanging">
<t hangText="RTP/AVP:">Use of the RTP<xref
target="RFC3550"></xref> protocol for media transport in
combination with the "RTP profile for audio and video
conferences with minimal control"<xref target="RFC3551"></xref>
over UDP. The usage is explained in RFC XXXX, appendix <xref
target="sec_rtp"></xref>.</t>
<t hangText="RTP/AVP/UDP:">the same as RTP/AVP.</t>
<t hangText="RTP/AVPF:">Use of the RTP<xref
target="RFC3550"></xref> protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)" <xref target="RFC4585"></xref> over UDP.
The usage is explained in RFC XXXX, appendix <xref
target="sec_rtp"></xref>.</t>
<t hangText="RTP/AVPF/UDP:">the same as RTP/AVPF.</t>
<t hangText="RTP/SAVP:">Use of the RTP<xref
target="RFC3550"></xref> protocol for media transport in
combination with the "The Secure Real-time Transport Protocol
(SRTP)" <xref target="RFC3711"></xref> over UDP. The usage is
explained in RFC XXXX, appendix <xref
target="sec_rtp"></xref>.</t>
<t hangText="RTP/SAVP/UDP:">the same as RTP/SAVP.</t>
<t hangText="RTP/SAVPF:">Use of the RTP<xref
target="RFC3550"></xref> protocol for media transport in
combination with the "<xref target="RFC5124"></xref> over UDP.
The usage is explained in RFC XXXX, appendix <xref
target="sec_rtp"></xref>.</t>
<t hangText="RTP/SAVPF/UDP:">the same as RTP/SAVPF.</t>
<t hangText="RTP/AVP/TCP:">Use of the RTP<xref
target="RFC3550"></xref> protocol for media transport in
combination with the "RTP profile for audio and video
conferences with minimal control"<xref target="RFC3551"></xref>
over TCP. The usage is explained in RFC XXXX, appendix <xref
target="sec_media-tcp-contrans"></xref>.</t>
<t hangText="RTP/AVPF/TCP:">Use of the RTP<xref
target="RFC3550"></xref> protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)"<xref target="RFC4585"> </xref> over TCP.
The usage is explained in RFC XXXX, appendix <xref
target="sec_media-tcp-contrans"></xref>.</t>
<t hangText="RTP/SAVP/TCP:">Use of the RTP<xref
target="RFC3550"></xref> protocol for media transport in
combination with the "The Secure Real-time Transport Protocol
(SRTP)" <xref target="RFC3711"></xref> over TCP. The usage is
explained in RFC XXXX, appendix <xref
target="sec_media-tcp-contrans"></xref>.</t>
<t hangText="RTP/SAVPF/TCP:">Use of the RTP<xref
target="RFC3550"></xref> protocol for media transport in
combination with the "<xref target="RFC5124"></xref> over TCP.
The usage is explained in RFC XXXX, appendix <xref
target="sec_media-tcp-contrans"></xref>.</t>
</list></t>
</section>
<section title="Transport modes">
<t>A registry for the transport parameter mode SHALL be defined with
the following rules: <list hangIndent="3" style="symbols">
<t>Registering requires an IETF Standards Action.</t>
<t>A contact person or organization with address and email.</t>
<t>A value definition that are following the ABNF token
definition.</t>
<t>A describing text that explains how the registered value are
used in RTSP.</t>
</list></t>
<t>This specification registers 1 value: <list hangIndent="6"
style="hanging">
<t hangText="PLAY:">See RFC XXXX.</t>
</list></t>
</section>
<section title="Transport Parameters">
<t>A registry for parameters that may be included in the Transport
header SHALL be defined with the following rules: <list
hangIndent="3" style="symbols">
<t>Registering uses the Specification Required policy.</t>
<t>A value definition that are following the ABNF token
definition.</t>
<t>A describing text that explains how the registered value are
used in RTSP.</t>
</list> This specification registers all the transport parameters
defined in <xref target="sec_Transport"></xref>.</t>
</section>
</section>
<section title="Cache Directive Extensions">
<t>There exist a number of cache directives which can be sent in the
Cache-Control header. A registry for this cache directives SHALL be
defined with the following rules: <list hangIndent="3" style="symbols">
<t>Registering requires an IETF Standards Action.</t>
<t>A registration is required to contain a contact person.</t>
<t>Name of the directive and a definition of the value, if
any.</t>
<t>Specification if it is an request or response directive.</t>
<t>A describing text that explains how the cache directive is used
for RTSP controlled media streams.</t>
</list></t>
<t>This specification registers the following values: <list
hangIndent="6" style="hanging">
<t hangText="no-cache:"></t>
<t hangText="public:"></t>
<t hangText="private:"></t>
<t hangText="no-transform:"></t>
<t hangText="only-if-cached:"></t>
<t hangText="max-stale:"></t>
<t hangText="min-fresh:"></t>
<t hangText="must-revalidate:"></t>
<t hangText="proxy-revalidate:"></t>
<t hangText="max-age:"></t>
</list></t>
</section>
<section title="Accept-Credentials">
<t>The security framework's TLS connection mechanism has two
registerable entities.</t>
<section title="Accept-Credentials policies">
<t>In <xref target="sec-frame-accept-cred"></xref> three policies
for how to handle certificates. Further policies may be defined and
SHALL be registered with IANA using the following rules: <list
hangIndent="3" style="symbols">
<t>Registering requires an IETF Standards Action</t>
<t>A registration is required to name a contact person.</t>
<t>Name of the policy.</t>
<t>A describing text that explains how the policy works for
handling the certificates.</t>
</list></t>
<t>This specification registers the following values: <list
hangIndent="6" style="hanging">
<t hangText="Any"></t>
<t hangText="Proxy"></t>
<t hangText="User"></t>
</list></t>
</section>
<section title="Accept-Credentials hash algorithms">
<t>The Accept-Credentials header (See <xref
target="sec_Accept-Credentials"></xref>) allows for the usage of
other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely
rare and could also be an interoperability problem. Therefore the
bar for registering new algorithms is placed intentional high.</t>
<t>Any registration of a new hash algorithm SHALL fulfill the
following requirement: <list hangIndent="3" style="symbols">
<t>Follow the IETF Standards Action policy.</t>
<t>A definition of the algorithm and its identifier meeting the
"token" ABNF requirement.</t>
</list></t>
</section>
</section>
<section title="Range header formats">
<t>The Range header allows for different range formats. New ones may
be registered, but moderation should be applied as it makes
interoperability more difficult. A registration SHALL fulfill the
following requirements: <list hangIndent="3" style="symbols">
<t>Follow the Specification Required policy.</t>
<t>A ABNF definition of the range format that fulfils the
"range-ext" definition.</t>
<t>A Contact person for the registration.</t>
<t>Rules for how one handles the range when using a negative
Scale.</t>
</list></t>
</section>
<section title="Media Property Values">
<t></t>
<section title="Description">
<t>The media streams being controlled by RTSP can have many
different properties. The media properties required to cover the use
cases that was in mind when writing the specification are defined.
However, it can be expected that further inovation will result in
new use cases or media streams with properties not covered by the
one specified here. Thus new ones can be specified. As new media
properties may need substantial amount of new definitions to
correctly specify behavior for this property the bar is intended to
be high.</t>
</section>
<section title="Registration Rules">
<t>Registering new media property SHALL fulfill the following
requirements</t>
<t><list style="symbols">
<t>Follow the Specification Required policy and get the approval
of the designated Expert.</t>
<t>Have a ABNF definition of the media property value name that
meets "media-prop-ext" definition</t>
<t>A Contact Person for the Registration</t>
<t>Description of all changes to the behavior of RTSP protocol
as result of these changes.</t>
</list></t>
</section>
<section title="Registered Values">
<t>This specification registers the 9 values listed in <xref
target="sec_Media-Properties"></xref>.</t>
</section>
</section>
<section title="Notify-Reason header">
<t></t>
<section title="Description">
<t>Notify-Reason values are the way to indicate why a notification
was sent. It may also imply that certain headers shall or should be
present required for the client to act upon the information the
notification carries. New notification behaviors do need to be
described to result in interoperable usage, thus specification are
required.</t>
</section>
<section title="Registration Rules">
<t>Registrations for new Notify-Reason value SHALL fulfill the
following requirements</t>
<t><list style="symbols">
<t>Follow the Specification Required policy and get the approval
of the designated Expert.</t>
<t>Have a ABNF definition of the Notify reason value name that
meets "Notify-Reason-extension" definition</t>
<t>A Contact Person for the Registration</t>
<t>Description of which headers shall be included in the request
and response, when it should be sent, and any affect it has on
the server client state.</t>
</list></t>
</section>
<section title="Registered Values">
<t>This specification registers 3 values defined in the
Notify-Reas-val ABNF<xref
target="sec_syntax-prot-header"></xref>:</t>
<t><list style="symbols">
<t>end-of-stream</t>
<t>media-properties-update</t>
<t>scale-change</t>
</list></t>
</section>
</section>
<section title="Seek-Style">
<t></t>
<section title="Description">
<t>New seek policies may be registered, however a large number of
these will complicate implementation substantially. The impact of
unknown policies is that the server will not honor the unknown and
use the server default policy instead.</t>
</section>
<section title="Registration Rules">
<t>Registrations of new Seek-Style polcies SHALL fulfill the
following requirements</t>
<t><list style="symbols">
<t>Follow the Specification Required policy.</t>
<t>Have a ABNF definition of the Seek-Style policy name that
meets "Seek-S-value-ext" definition</t>
<t>A Contact Person for the Registration</t>
<t>Description of which headers shall be included in the request
and response, when it should be sent, and any affect it has on
the server client state.</t>
</list></t>
</section>
<section title="Registered Values">
<t>This specification registers 3 values:</t>
<t><list style="symbols">
<t>RAP</t>
<t>First-Prior</t>
<t>Next</t>
</list></t>
</section>
</section>
<section anchor="sec_iana-uri-schemes" title="URI Schemes">
<t>This specification defines two URI schemes ("rtsp" and "rtsps") and
reserves a third one ("rtspu"). Registrations are following RFC
4395<xref target="RFC4395"></xref>.</t>
<section title="The rtsp URI Scheme">
<t><list hangIndent="6" style="hanging">
<t hangText="URI scheme name:">rtsp</t>
<t hangText="Status:">Permanent</t>
<t hangText="URI scheme syntax:">See <xref
target="sec_syntax-prot-generic"></xref> of RFC XXXX.</t>
<t hangText="URI scheme semantics:">The rtsp scheme is used to
indicate resources accessible through the usage of the Real-time
Streaming Protocol (RTSP). RTSP allows different operations on
the resource identified by the URI, but the primary purpose is
the streaming delivery of the resource to a client. However the
operations that are currently defined are: Describing the
resource for the purpose of configuring the receiving entity
(DESCRIBE), configuring the delivery method and its addressing
(SETUP), controlling the delivery (PLAY and PAUSE), reading or
setting of resource related parameters (SET_PARAMETER and
GET_PARAMETER, and termination of the session context created
(TEARDOWN).</t>
<t hangText="Encoding considerations:">IRIs in this scheme are
defined and needs to be encoded as RTSP URIs when used within
the RTSP protocol. That encoding is done according to RFC
3987.</t>
<t
hangText="Applications/protocols that use this URI scheme name:">RTSP
1.0 (RFC 2326), RTSP 2.0 (RFC XXXX)</t>
<t hangText="Interoperability considerations:">The change in URI
syntax performed between RTSP 1.0 and 2.0 can create
interoperability issues.</t>
<t hangText="Security considerations:">All the security threats
identified in Section 7 of RFC 3986 applies also to this scheme.
They needs to be reviewed and considered in any implementation
utilizing this scheme.</t>
<t hangText="Contact:">Magnus Westerlund,
magnus.westerlund@ericsson.com</t>
<t hangText="Author/Change controller:">IETF</t>
<t hangText="References:">RFC 2326, RFC 3986, RFC 3987, RFC
XXXX</t>
</list></t>
</section>
<section title="The rtsps URI Scheme">
<t><list hangIndent="6" style="hanging">
<t hangText="URI scheme name:">rtsps</t>
<t hangText="Status:">Permanent</t>
<t hangText="URI scheme syntax:">See <xref
target="sec_syntax-prot-generic"></xref> of RFC XXXX.</t>
<t hangText="URI scheme semantics:">The rtsps scheme is used to
indicate resources accessible through the usage of the Real-time
Streaming Protocol (RTSP) over TLS. RTSP allows different
operations on the resource identified by the URI, but the
primary purpose is the streaming delivery of the resource to a
client. However the operations that are currently defined are:
Describing the resource for the purpose of configuring the
receiving entity (DESCRIBE), configuring the delivery method and
its addressing (SETUP), controlling the delivery (PLAY and
PAUSE), reading or setting of resource related parameters
(SET_PARAMETER and GET_PARAMETER, and termination of the session
context created (TEARDOWN).</t>
<t hangText="Encoding considerations:">IRIs in this scheme are
defined and needs to be encoded as RTSP URIs when used within
the RTSP protocol. That encoding is done according to RFC
3987.</t>
<t
hangText="Applications/protocols that use this URI scheme name:">RTSP
1.0 (RFC 2326), RTSP 2.0 (RFC XXXX)</t>
<t hangText="Interoperability considerations:">The change in URI
syntax performed between RTSP 1.0 and 2.0 can create
interoperability issues.</t>
<t hangText="Security considerations:">All the security threats
identified in Section 7 of RFC 3986 applies also to this scheme.
They needs to be reviewed and considered in any implementation
utilizing this scheme.</t>
<t hangText="Contact:">Magnus Westerlund,
magnus.westerlund@ericsson.com</t>
<t hangText="Author/Change controller:">IETF</t>
<t hangText="References:">RFC 2326, RFC 3986, RFC 3987, RFC
XXXX</t>
</list></t>
</section>
<section title="The rtspu URI Scheme">
<t><list hangIndent="6" style="hanging">
<t hangText="URI scheme name:">rtspu</t>
<t hangText="Status:">Permanent</t>
<t hangText="URI scheme syntax:">See Section 3.2 of RFC
2326.</t>
<t hangText="URI scheme semantics:">The rtspu scheme is used to
indicate resources accessible through the usage of the Real-time
Streaming Protocol (RTSP) over unrelaible datagram transport.
RTSP allows different operations on the resource identified by
the URI, but the primary purpose is the streaming delivery of
the resource to a client. However the operations that are
currently defined are: Describing the resource for the purpose
of configuring the receiving entity (DESCRIBE), configuring the
delivery method and its addressing (SETUP), controlling the
delivery (PLAY and PAUSE), reading or setting of resource
related parameters (SET_PARAMETER and GET_PARAMETER, and
termination of the session context created (TEARDOWN).</t>
<t hangText="Encoding considerations:">IRIs in this scheme are
defined and needs to be encoded as RTSP URIs when used within
the RTSP protocol. That encoding is done according to RFC
3987.</t>
<t
hangText="Applications/protocols that use this URI scheme name:">RTSP
1.0 (RFC 2326)</t>
<t hangText="Interoperability considerations:">The definition of
the transport mechanism of RTSP over UDP has interoperability
issues. That makes the usage of this scheme problematic.</t>
<t hangText="Security considerations:">All the security threats
identified in Section 7 of RFC 3986 applies also to this scheme.
They needs to be reviewed and considered in any implementation
utilizing this scheme.</t>
<t hangText="Contact:">Magnus Westerlund,
magnus.westerlund@ericsson.com</t>
<t hangText="Author/Change controller:">IETF</t>
<t hangText="References:">RFC 2326, RFC 3986, RFC 3987</t>
</list></t>
</section>
</section>
<section title="SDP attributes">
<t>This specification defines three SDP <xref target="RFC4566"></xref>
attributes that it is requested that IANA register. <figure>
<artwork><![CDATA[
SDP Attribute ("att-field"):
Attribute name: range
Long form: Media Range Attribute
Type of name: att-field
Type of attribute: Media and session level
Subject to charset: No
Purpose: RFC XXXX
Reference: RFC XXXX
Values: See ABNF definition.
Attribute name: control
Long form: RTSP control URI
Type of name: att-field
Type of attribute: Media and session level
Subject to charset: No
Purpose: RFC XXXX
Reference: RFC XXXX
Values: Absolute or Relative URIs.
Attribute name: etag
Long form: Entity Tag
Type of name: att-field
Type of attribute: Media and session level
Subject to charset: No
Purpose: RFC XXXX
Reference: RFC XXXX
Values: See ABNF definition
]]></artwork>
</figure></t>
</section>
<section title="Media Type Registration for text/parameters">
<t></t>
<t><list style="hanging">
<t hangText="Type name:">text</t>
<t hangText="Subtype name:">parameters</t>
<t hangText="Required parameters:"></t>
<t hangText="Optional parameters:"></t>
<t hangText="Encoding considerations:"></t>
<t hangText="Security considerations:">This format may carry any
type of parameters. Some can clear have security requirements,
like privacy, confidentiality or integrity requirements. The
format has no built in security protection. For the usage it was
defined the transport can be protected between server and client
using TLS. However, care must be take to consider if also the
proxies are trusted with the parameters in case hop-by-hop
security is used. If stored as file in file system the necessary
precautions needs to be taken in relation to the parameters
requirements including object security such as S/MIME <xref
target="RFC3851"></xref>.</t>
<t hangText="Interoperability considerations:">This media type was
mentioned as a fictional example in RFC 2326 but was not formally
specified. This have resulted in usage of this media type which
may not match its formal definition.</t>
<t hangText="Published specification:">RFC XXXX, <xref
target="sec_text-parameters"></xref>.</t>
<t hangText="Applications that use this media type:">Applications
that use RTSP and have additional parameters they like to read and
set using the RTSP GET_PARAMETER and SET_PARAMETER methods.</t>
<t hangText="Additional information:"></t>
<t hangText="Magic number(s):"></t>
<t hangText="File extension(s):"></t>
<t hangText="Macintosh file type code(s): "></t>
<t
hangText="Person & email address to contact for further information:">Magnus
Westerlund (magnus.westerlund@ericsson.com)</t>
<t hangText="Intended usage: ">Common</t>
<t hangText="Restrictions on usage: ">None</t>
<t hangText="Author:">Magnus Westerlund
(magnus.westerlund@ericsson.com)</t>
<t hangText="Change controller:">IETF</t>
<t hangText="Addition Notes:"></t>
</list></t>
<t></t>
</section>
</section>
<!-- title="IANA Considerations" -->
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.4566" ?>
<?rfc include="reference.RFC.3551" ?>
<?rfc include="reference.RFC.2616" ?>
<?rfc include="reference.RFC.5234" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.5124" ?>
<?rfc include="reference.RFC.3987" ?>
<?rfc include="reference.RFC.3986" ?>
<?rfc include="reference.RFC.4346" ?>
<?rfc include="reference.RFC.2617" ?>
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.3629" ?>
<?rfc include="reference.RFC.3280" ?>
<?rfc include="reference.RFC.4648" ?>
<?rfc include='reference.RFC.4086'?>
<?rfc include="reference.RFC.4395" ?>
<reference anchor="3gpp-26234">
<front>
<title>Transparent end-to-end Packet-switched Streaming Service
(PSS); Protocols and codecs; Technical Specification 26.234</title>
<author initials="" surname="">
<organization>Third Generation Partnership Project
(3GPP)</organization>
</author>
<date month="December" year="2002" />
</front>
</reference>
<reference anchor="FIPS-pub-180-2">
<front>
<title>Federal Information Processing Standards Publications (FIPS
PUBS) 180-2: Secure Hash Standard</title>
<author initials="" surname="">
<organization>National Institute of Standards and Technology
(NIST)</organization>
</author>
<date month="Augusti" year="2002" />
</front>
<format target="http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf"
type="PDF" />
</reference>
<?rfc include="reference.RFC.3550" ?>
<?rfc include="reference.RFC.2818" ?>
<?rfc include="reference.I-D.narten-iana-considerations-rfc2434bis" ?>
<?rfc include="reference.RFC.4585" ?>
<?rfc include="reference.RFC.3711" ?>
<?rfc include="reference.RFC.4567" ?>
<?rfc include="reference.RFC.3830" ?>
<?rfc include="reference.RFC.4571" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include='reference.RFC.3851'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2068" ?>
<?rfc include="reference.RFC.2326" ?>
<?rfc include="reference.RFC.3388" ?>
<?rfc include="reference.RFC.1123" ?>
<?rfc include="reference.RFC.1644" ?>
<?rfc include="reference.RFC.2070" ?>
<?rfc include="reference.RFC.4145" ?>
<?rfc include="reference.I-D.ietf-mmusic-rtsp-nat"?>
<?rfc include='reference.RFC.2974'?>
<!--
[27] ISO/IEC, "Information technology generic coding of moving
pictures and associated audio information: Systems," Published
standard ISO 13818-1:2000, International Organization for
Standardization ISO/IEC, Geneva, Switzerland, Oct. 2000
-->
<reference anchor="ISO.13818-1.2000">
<front>
<title>Information technology - Generic coding of moving pictures
and associated audio information: Systems</title>
<author>
<organization>International Organization for
Standardization</organization>
</author>
<date month="December" year="2000" />
</front>
<seriesInfo name="ISO/IEC" value="13818-1:2000" />
</reference>
<!--
[28] H. Schulzrinne, "A comprehensive multimedia control architecture
for the Internet," in Proc. International Workshop on Network and
Operating System Support for Digital Audio and Video (NOSSDAV), (St.
Louis, Missouri), May 1997.
-->
<reference anchor="NOSSDAV-1997-1">
<front>
<title>A comprehensive multimedia control architecture for the
Internet</title>
<author initials="H." surname="Schulzrinne">
<organization>Network and Operating System Support for Digital
Audio and Video (NOSSDAV)</organization>
</author>
<date month="May" year="1997" />
</front>
</reference>
<?rfc include="reference.RFC.3261" ?>
<!--
&rfc3261;
-->
<!--
[29] International Telecommunication Union, "Visual telephone systems
and equipment for local area networks which provide a non-guaranteed
quality of service," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, May 1996.
-->
<reference anchor="ITU.H323.1996">
<front>
<title>Visual telephone systems and equipment for local area
networks which provide a non-guaranteed quality of service</title>
<author>
<organization>International Telecommunications
Union</organization>
</author>
<date month="May" year="1996" />
</front>
<seriesInfo name="ITU-T" value="Recommendation H.323" />
</reference>
<?rfc include="reference.RFC.1961" ?>
<!--
&rfc1961;
-->
<!--
[31] J. Miller, P. Resnick, and D. Singer, "Rating services and
rating systems (and their machine readable descriptions),"
Recommendation REC-PICS-services-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996.
-->
<reference anchor="W3C.REC-PICS-services">
<front>
<title>Rating services and rating systems (and their machine
readable descriptions)</title>
<author initials="J." surname="Miller">
<organization></organization>
</author>
<author initials="P." surname="Resnick">
<organization></organization>
</author>
<author initials="D." surname="Singer">
<organization></organization>
</author>
<date month="October" year="1996" />
</front>
<seriesInfo name="W3C" value="REC-PICS-services-961031" />
</reference>
<!--
[32] J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS label
distribution label syntax and communication protocols,"
Recommendation REC-PICS-labels-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996.
-->
<reference anchor="W3C.REC-PICS-labels">
<front>
<title>PICS label distribution label syntax and communication
protocols</title>
<author initials="J." surname="Miller">
<organization></organization>
</author>
<author initials="T." surname="Krauskopf">
<organization></organization>
</author>
<author initials="P." surname="Resnick">
<organization></organization>
</author>
<author initials="W." surname="Treese">
<organization></organization>
</author>
<date month="" year="" />
</front>
<seriesInfo name="W3C" value="REC-PICS-labels-961031" />
</reference>
<?rfc include="reference.RFC.1305" ?>
<!--
[34] ISO/IEC, "Information technology - generic coding of moving
pictures and associated audio informaiton - part 6: extension for
digital storage media and control," Draft International Standard ISO
13818-6, International Organization for Standardization ISO/IEC
JTC1/SC29/WG11, Geneva, Switzerland, Nov. 1995.
-->
<reference anchor="ISO.13818-6.1995">
<front>
<title>Information technology - Generic coding of moving pictures
and associated audio information - part 6: Extension for digital
storage media and control</title>
<author>
<organization>International Organization for
Standardization</organization>
</author>
<date month="November" year="1995" />
</front>
<seriesInfo name="ISO" value="Draft Standard 13818-6" />
</reference>
<!--
[35] ISO/IEC, "Data elements and interchange formats - information
interchange - representation of dates and times," Published standard
ISO 8601, International Organization for Standardization ISO/IEC,
Geneva, Switzerland, Dec. 2000.
-->
<reference anchor="ISO.8601.2000">
<front>
<title>Data elements and interchange formats - Information
interchange - Representation of dates and times</title>
<author>
<organization>International Organization for
Standardization</organization>
</author>
<date month="December" year="2000" />
</front>
<seriesInfo name="ISO/IEC" value="Standard 8601" />
</reference>
</references>
<section anchor="sec_examples" title="Examples">
<t>This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However remember that this
is examples and the normative and syntax description in the other
sections takes precedence. Please also note that many of the example
contain syntax illegal line breaks to accommodate the formatting
restriction that the RFC series impose.</t>
<section anchor="sec-examples-mod-unicast"
title="Media on Demand (Unicast)">
<t>The 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
storage entity in which multiple continuous media types pertaining to
the same end-user presentation are present. In effect, the container
file represents an RTSP presentation, with each of its components
being RTSP controlled media streams. Container files are a widely used
means to store such presentations. While the components are
transported as independent streams, it is desirable to maintain a
common context for those streams at the server end.</t>
<t><list style="hanging">
<t>This enables the server to keep a single storage handle open
easily. It also allows treating all the streams equally in case of
any prioritization of streams by the server.</t>
</list></t>
<t>It is also possible that the presentation author may wish to
prevent selective retrieval of the streams by the client in order to
preserve the artistic effect of the combined media presentation.
Similarly, in such a tightly bound presentation, it is desirable to be
able to control all the streams via a single control message using an
aggregate URI.</t>
<t>The following is an example of using a single RTSP session to
control multiple streams. It also illustrates the use of aggregate
URIs. In a container file it is also desirable to not write any URI
parts which is not kept, when the container is distributed, like the
host and most of the path element. Therefore this example also uses
the "*" and relative URI in the delivered SDP.</t>
<t>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 the
container file. <figure>
<artwork><![CDATA[
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4]]></artwork>
</figure><figure>
<artwork><![CDATA[C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678
Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13
Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT
]]></artwork>
</figure><figure>
<artwork><![CDATA[C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30-
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678
Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678
Range: npt=34.57-623.10
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6
User-Agent: PhonyClient/1.2
Range: npt=34.57-623.10
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 6
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678
Range: npt=34.57-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889
]]></artwork>
</figure></t>
</section>
<section anchor="sec-examples-mod-unicast-pipelining"
title="Media on Demand using Pipelining">
<t>This example is basically the example above (<xref
target="sec-examples-mod-unicast"></xref>), but now utilizing
pipelining to speed up the setup. It requires only two round trip
times until the media starts flowing. First of all, the session
description is retrieved to determine what media resources need to be
setup. In the second step, one sends the necessary SETUP requests and
the PLAY request to initiate media delivery.</t>
<t>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 the
container file. <figure>
<artwork><![CDATA[
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC
Pipelined-Requests: 7654
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Accept-Ranges: NPT, SMPTE, UTC
Pipelined-Requests: 7654
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30-
Session: 12345678
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13
Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678
Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654]]></artwork>
</figure></t>
</section>
<section title="Media on Demand (Unicast)">
<t>An alternative example of media on demand with a bit more tweaks is
the following. Client C requests a movie distributed from two
different media servers A (audio.example.com) and V (
video.example.com). The media description is stored on a web server W.
The media description contains descriptions of the presentation and
all its streams, including the codecs that are available, dynamic RTP
payload types, the protocol stack, and content information such as
language or copyright restrictions. It may also give an indication
about the timeline of the movie.</t>
<t>In this example, the client is only interested in the last part of
the movie. <figure>
<artwork><![CDATA[
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 264
Expires: 23 Jan 1998 15:35:06 GMT
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
e=adm@example.com
a=range:npt=0-1:49:34
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public
Accept-Ranges: NPT, SMPTE]]></artwork>
</figure><figure>
<artwork><![CDATA[C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059";
src_addr="192.0.2.5:5002"/"192.0.2.5:5003"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:35:13 GMT]]></artwork>
</figure><figure>
<artwork><![CDATA[C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 12345678
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:52 GMT
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 23456789
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:36:52 GMT
]]></artwork>
</figure></t>
<t>Even though the audio and video track are on two different servers,
may start at slightly different times, and may drift with respect to
each other, the client can perform initial synchronize of the two
media using RTP-Info and Range received in the PLAY responses. If the
two servers are time synchronized the RTCP packets can also be used to
maintain synchronization.</t>
</section>
<section title="Single Stream Container Files">
<t>Some RTSP servers may treat all files as though they are "container
files", yet other servers may not support such a concept. Because of
this, clients needs to use the rules set forth in the session
description for Request-URIs, rather than assuming that a consistent
URI may always be used throughout. Below are an example of how a
multi-stream server might expect a single-stream file to be served:
<figure>
<artwork><![CDATA[
C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0
Accept: application/x-rtsp-mh, application/sdp
CSeq: 1
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp
Content-length: 148
Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT
Expires: 23 Jan 1997 17:00:00 GMT
v=0
o=- 872653257 872653257 IN IP4 192.0.2.5
s=mu-law wave file
i=audio test
t=0 0
a=control: *
m=audio 0 RTP/AVP 0
a=control:streamid=0
]]></artwork>
</figure><figure>
<artwork><![CDATA[C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2
User-Agent: PhonyClient/1.2
Accept-Ranges: NPT, SMPTE, UTC
S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971";
src_addr="192.0.2.5:6970"/"192.0.2.5:6971";
mode="PLAY";ssrc=EAB98712
CSeq: 2
Session: 2034820394
Expires: 23 Jan 1997 16:00:00 GMT
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT
Accept-Ranges: NPT]]></artwork>
</figure><figure>
<artwork><![CDATA[
C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 2034820394
S->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:08 GMT
Session: 2034820394
Range: npt=0-600
RTP-Info: url="rtsp://foo.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123]]></artwork>
</figure></t>
<t>Note the different URI in the SETUP command, and then the switch
back to the aggregate URI in the PLAY command. This makes complete
sense when there are multiple streams with aggregate control, but is
less than intuitive in the special case where the number of streams is
one. However the server has declared that the aggregated control URI
in the SDP and therefore this is legal.</t>
<t>In this case, it is also required that servers accept
implementations that use the non-aggregated interpretation and use the
individual media URI, like this: <figure>
<artwork><![CDATA[
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
]]></artwork>
</figure></t>
</section>
<section anchor="sec_example-live-multicast"
title="Live Media Presentation Using Multicast">
<t>The media server M chooses the multicast address and port. Here, it
is assumed that the web server only contains a pointer to the full
description, while the media server M maintains the full description.
<figure>
<artwork><![CDATA[
C->W: GET /sessions.html HTTP/1.1
Host: www.example.com
W->C: HTTP/1.1 200 OK
Content-Type: text/html
<html>
...
<href "Streamed Live Music performance"
src="rtsp://live.example.com/concert/audio">
...
</html>
]]></artwork>
</figure><figure>
<artwork><![CDATA[C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 182
Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT
Supported: play.basic
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
m=audio 3456 RTP/AVP 0
c=IN IP4 224.2.0.1/16
a=control: rtsp://live.example.com/concert/audio
a=range:npt=0-]]></artwork>
</figure><figure>
<artwork><![CDATA[C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;multicast
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT
Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/"
224.2.0.1:3457";ttl=16
Session: 0456804596
Accept-Ranges: NPT, UTC
]]></artwork>
</figure><figure>
<artwork><![CDATA[C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3
Session: 0456804596
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT
Session: 0456804596
Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000
]]></artwork>
</figure></t>
</section>
<section anchor="sec_capability-example" title="Capability Negotiation">
<t>This examples illustrate how the client and server determines their
capability to support a special feature, in this case "play.scale".
The server, through the clients request and the included Supported
header, learns the client supports RTSP 2.0, and also supports the
playback time scaling feature of RTSP. The server's response contains
the following feature related information to the client; it supports
the basic playback (play.basic), the extended functionality of time
scaling of content (play.scale), and one "example.com" proprietary
feature (com.example.flight). The client also learns the methods
supported (Public header) by the server for the indicated resource.
<figure>
<artwork><![CDATA[
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Server: PhonyServer/2.0
Supported: play.basic, play.scale, com.example.flight
]]></artwork>
</figure></t>
<t>When the client sends its SETUP request it tells the server that it
is requires support of the play.scale feature for this session by
including the Require header. <figure>
<artwork><![CDATA[
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Server: PhonyServer/2.0
Accept-Ranges: NPT, SMPTE]]></artwork>
</figure></t>
</section>
</section>
<!-- title="Examples" -->
<section anchor="sec_machine" title="RTSP Protocol State Machine">
<t>The RTSP session state machine describes the behavior of the protocol
from RTSP session initialization through RTSP session termination.</t>
<t>The State machine is defined on a per session basis which is uniquely
identified by the RTSP session identifier. The session may contain one
or more media streams depending on state. If a single media stream is
part of the session it is in non-aggregated control. If two or more is
part of the session it is in aggregated control.</t>
<t>The below state machine is a normative description of the protocols
behavior. However, in case of ambiguity with the earlier parts of this
specification, the description in the earlier parts SHALL take
precedence.</t>
<section title="States">
<t>The state machine contains three states, described below. For each
state there exist a table which shows which requests and events that
is allowed and if they will result in a state change. <list
hangIndent="6" style="hanging">
<t hangText="Init:">Initial state no session exist.</t>
<t hangText="Ready:">Session is ready to start playing.</t>
<t hangText="Play:">Session is playing, i.e. sending media stream
data in the direction S->C.</t>
</list></t>
</section>
<section title="State variables">
<t>This representation of the state machine needs more than its state
to work. A small number of variables are also needed and is explained
below. <list hangIndent="6" style="hanging">
<t hangText="NRM:">The number of media streams part of this
session.</t>
<t hangText="RP:">Resume point, the point in the presentation time
line at which a request to continue will resume from. A time
format for the variable is not mandated.</t>
</list></t>
</section>
<section title="Abbreviations">
<t>To make the state tables more compact a number of abbreviations are
used, which are explained below. <list hangIndent="6" style="hanging">
<t hangText="IFI:">IF Implemented.</t>
<t hangText="md:">Media</t>
<t hangText="PP:">Pause Point, the point in the presentation time
line at which the presentation was paused.</t>
<t hangText="Prs:">Presentation, the complete multimedia
presentation.</t>
<t hangText="RedP:">Redirect Point, the point in the presentation
time line at which a REDIRECT was specified to occur.</t>
<t hangText="SES:">Session.</t>
</list></t>
</section>
<section title="State Tables">
<t>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
events which is method names are, unless noted, requests with the
given method in the direction client to server (C->S). In some
cases there exist one or more requisite. The response column tells
what type of response actions should be performed. Possible actions
that is requested for an event includes: response codes, e.g. 200,
headers that MUST be included in the response, setting of state
variables, or setting of other session related parameters. The new
state column tells which state the state machine changes to.</t>
<t>The response to valid request meeting the requisites is normally a
2xx (SUCCESS) unless other noted in the response column. The
exceptions needs to be given a response according to the response
column. If the request does not meet the requisite, is erroneous or
some other type of error occur the appropriate response code MUST 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 ended and its
state is changed to Init. A response code of 304 results in no state
change. However there exist restrictions to when a 3rr response may be
used. A 5xx response SHALL not result in any change of the session
state, except if the error is not possible to recover from. A
unrecoverable error SHALL result the ending of the 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 the case that the next
request after a 5xx is responded with 454 (Session Not Found) the
client knows that the session has ended.</t>
<t>The server will timeout the session after the period of time
specified in the SETUP response, if no activity from the client is
detected. Therefore there exist a timeout event for all states except
Init.</t>
<t>In the case that NRM = 1 the presentation URI is equal to the media
URI or a specified presentation URI. For NRM > 1 the presentation
URI MUST be other than any of the medias that are part of the session.
This applies to all states. <texttable anchor="tab_state-nochange"
title="None state-machine changing events">
<preamble />
<ttcol align="left">Event</ttcol>
<ttcol align="left">Prerequisite</ttcol>
<ttcol align="left">Response</ttcol>
<c>DESCRIBE</c>
<c>Needs REDIRECT</c>
<c>3rr, Redirect</c>
<c>DESCRIBE</c>
<c />
<c>200, Session description</c>
<c>OPTIONS</c>
<c>Session ID</c>
<c>200, Reset session timeout timer</c>
<c>OPTIONS</c>
<c />
<c>200</c>
<c>SET_PARAMETER</c>
<c>Valid parameter</c>
<c>200, change value of parameter</c>
<c>GET_PARAMETER</c>
<c>Valid parameter</c>
<c>200, return value of parameter</c>
</texttable></t>
<t>The methods in <xref target="tab_state-nochange" /> do not have any
effect on the state machine or the state variables. However some
methods do change other session related parameters, for example
SET_PARAMETER which will set the parameter(s) specified in its body.
Also all of these methods that allows Session header will also update
the keep-alive timer for the session. <texttable
anchor="tab_state-init" title="State: Init">
<preamble />
<ttcol align="left">Action</ttcol>
<ttcol align="left">Requisite</ttcol>
<ttcol align="left">New State</ttcol>
<ttcol align="left">Response</ttcol>
<c>SETUP</c>
<c />
<c>Ready</c>
<c>NRM=1, RP=0.0</c>
<c>SETUP</c>
<c>Needs Redirect</c>
<c>Init</c>
<c>3rr Redirect</c>
<c>S -> C: REDIRECT</c>
<c>No Session hdr</c>
<c>Init</c>
<c>Terminate all SES</c>
</texttable></t>
<t>The initial state of the state machine, see <xref
target="tab_state-init" /> can only be left by processing a correct
SETUP request. As seen in the table the two state variables are also
set by a correct request. This table also shows that a correct SETUP
can in some cases be redirected to another URI and/or server by a 3rr
response. <texttable anchor="tab_state-ready" title="State: Ready">
<preamble />
<ttcol align="left">Action</ttcol>
<ttcol align="left">Requisite</ttcol>
<ttcol align="left">New State</ttcol>
<ttcol align="left">Response</ttcol>
<c>SETUP</c>
<c>New URI</c>
<c>Ready</c>
<c>NRM +=1</c>
<c>SETUP</c>
<c>URI Setup prior</c>
<c>Ready</c>
<c>Change transport param</c>
<c>TEARDOWN</c>
<c>Prs URI,</c>
<c>Init</c>
<c>No session hdr, NRM = 0</c>
<c>TEARDOWN</c>
<c>md URI,NRM=1</c>
<c>Init</c>
<c>No Session hdr, NRM = 0</c>
<c>TEARDOWN</c>
<c>md URI,NRM>1</c>
<c>Ready</c>
<c>Session hdr, NRM -= 1</c>
<c>PLAY</c>
<c>Prs URI, No range</c>
<c>Play</c>
<c>Play from RP</c>
<c>PLAY</c>
<c>Prs URI, Range</c>
<c>Play</c>
<c>According to range</c>
<c>PAUSE</c>
<c>Prs URI</c>
<c>Ready</c>
<c>Return PP</c>
<c>SC:REDIRECT</c>
<c>Range hdr</c>
<c>Ready</c>
<c>Set RedP</c>
<c>SC:REDIRECT</c>
<c>no range hdr</c>
<c>Init</c>
<c>Session is removed</c>
<c>Timeout</c>
<c />
<c>Init</c>
<c />
<c>RedP reached</c>
<c />
<c>Init</c>
<c>TEARDOWN of session</c>
</texttable></t>
<t>In the Ready state, see <xref target="tab_state-ready" />, some of
the actions are depending 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 either add one more media stream to the session or
if the media stream (same URI) already is part of the session change
the transport parameters. TEARDOWN is depending on both the
Request-URI and the number of media stream within the session. If the
Request-URI is the presentations URI the whole session is torn down.
If a media URI is used in the TEARDOWN request and more than one media
exist in the session, the session will remain and a session header
MUST be returned in the response. If only a single media stream
remains in the session when performing a TEARDOWN with a media URI the
session is removed. The number of media streams remaining after
tearing down a media stream determines the new state. <texttable
anchor="tab_state-play" title="State: Play">
<preamble />
<ttcol align="left">Action</ttcol>
<ttcol align="left">Requisite</ttcol>
<ttcol align="left">New State</ttcol>
<ttcol align="left">Response</ttcol>
<c>PAUSE</c>
<c>PrsURI</c>
<c>Ready</c>
<c>Set RP to present point</c>
<c>PP reached</c>
<c />
<c>Ready</c>
<c>RP = PP</c>
<c>End of media</c>
<c>All media</c>
<c>Play</c>
<c>Set RP = End of media</c>
<c>End of range</c>
<c />
<c>Play</c>
<c>Set RP = End of range</c>
<c>PLAY</c>
<c>Prs URI, No range</c>
<c>Play</c>
<c>Play from present point</c>
<c>PLAY</c>
<c>Prs URI, Range</c>
<c>Play</c>
<c>According to range</c>
<c>PLAY_NOTIFY</c>
<c />
<c>Play</c>
<c>200</c>
<c>SETUP</c>
<c>New URI</c>
<c>Play</c>
<c>455</c>
<c>SETUP</c>
<c>Setuped URI</c>
<c>Play</c>
<c>455</c>
<c>SETUP</c>
<c>Setuped URI, IFI</c>
<c>Play</c>
<c>Change transport param.</c>
<c>TEARDOWN</c>
<c>Prs URI</c>
<c>Init</c>
<c>No session hdr</c>
<c>TEARDOWN</c>
<c>md URI,NRM=1</c>
<c>Init</c>
<c>No Session hdr, NRM=0</c>
<c>TEARDOWN</c>
<c>md URI</c>
<c>Play</c>
<c>455</c>
<c>SC:REDIRECT</c>
<c>Range hdr</c>
<c>Play</c>
<c>Set RedP</c>
<c>SC:REDIRECT</c>
<c>no range hdr</c>
<c>Init</c>
<c>Session is removed</c>
<c>RedP reached</c>
<c />
<c>Init</c>
<c>TEARDOWN of session</c>
<c>Timeout</c>
<c />
<c>Init</c>
<c>Stop Media playout</c>
</texttable></t>
<t>The Play state table, see <xref target="tab_state-play"></xref>, is
the largest. The table contains an number of requests that has
presentation URI as a prerequisite on the Request-URI, this is due to
the exclusion of non-aggregated stream control in sessions with more
than one media stream.</t>
<t>To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End of
media" event when all media has finished playing, the session still
remain in Play state. An explicit PAUSE request MUST be sent to change
the state to Ready. It may appear that there exist an automatic
transitions in "RedP reached" and "PP reached", however they are
requested and acknowledge before they take place. The time at which
the transition will happen is known by looking at the range header. If
the client sends request close in time to these transitions it needs
to be prepared for getting error message as the state may or may not
have changed.</t>
</section>
</section>
<!-- title="RTSP Protocol State Machine" -->
<section anchor="sec_mediatran" title="Media Transport Alternatives">
<t>This section defines how certain combinations of protocols, profiles
and lower transports are used. This includes the usage of the Transport
header's source and destination address parameters "src_addr" and
"dest_addr".</t>
<section anchor="sec_rtp" title="RTP">
<t>This section defines the interaction of RTSP with respect to the
RTP protocol <xref target="RFC3550"></xref>. It also defines any
necessary media transport signalling with regards to RTP.</t>
<t>The available RTP profiles and lower layer transports are described
below along with rules on signalling the available combinations.</t>
<section anchor="sec_mediatran-rtp-avp" title="AVP">
<t>The usage of the "RTP Profile for Audio and Video Conferences
with Minimal Control" <xref target="RFC3551"></xref> when using RTP
for media transport over different lower layer transport protocols
is defined below in regards to RTSP.</t>
<t>One such case is defined within this document, the use of
embedded (interleaved) binary data as defined in <xref
target="sec_binary"></xref>. The usage of this method is indicated
by include the "interleaved" parameter.</t>
<t>When using embedded binary data the "src_addr" and "dest_addr"
SHALL NOT be used. This addressing and multiplexing is used as
defined with use of channel numbers and the interleaved
parameter.</t>
</section>
<section title="AVP/UDP">
<t>This part describes sending of RTP <xref target="RFC3550"></xref>
over lower transport layer UDP <xref target="RFC0768"></xref>
according to the profile "RTP Profile for Audio and Video
Conferences with Minimal Control" defined in RFC 3551 <xref
target="RFC3551"></xref>. This profiles requires one or two uni- or
bi-directional UDP flows per media stream. The first UDP flow is for
RTP and the second is for RTCP. Embedding of RTP data with the RTSP
messages, in accordance with <xref target="sec_binary"></xref>,
SHOULD NOT be performed when RTSP messages are transported over
unreliable transport protocols, like UDP <xref
target="RFC0768"></xref>.</t>
<t>The RTP/UDP and RTCP/UDP flows can be established using the
Transport header's "src_addr", and "dest_addr" parameters.</t>
<t>In RTSP PLAY mode, the transmission of RTP packets from client to
server is unspecified. The behavior in regards to such RTP packets
MAY be defined in future.</t>
<t>The "src_addr" and "dest_addr" parameters are used in the
following way for media playback, i.e. Mode=PLAY: <list
hangIndent="3" style="symbols">
<t>The "src_addr" and "dest_addr" parameters MUST contain either
1 or 2 address specifications.</t>
<t>Each address specification for RTP/AVP/UDP or RTP/AVP/TCP
MUST contain either: <list hangIndent="3" style="symbols">
<t>both an address and a port number, or</t>
<t>a port number without an address.</t>
</list></t>
<t>The first address and port pair given in either of the
parameters applies to the RTP stream. The second address and
port pair if present applies to the RTCP stream.</t>
<t>The RTP/UDP packets from the server to the client SHALL be
sent to the address and port given by first address and port
pair of the "dest_addr" parameter.</t>
<t>The RTCP/UDP packets from the server to the client SHALL be
sent to the address and port given by the second address and
port pair of the "dest_addr" parameter. If no second pair is
specified RTCP SHALL NOT be sent.</t>
<t>The RTCP/UDP packets from the client to the server SHALL be
sent to the address and port given by the second address and
port pair of the "src_addr" parameter. If no second pair is
given RTCP SHALL NOT be sent.</t>
<t>The RTP/UDP packets from the client to the server SHALL be
sent to the address and port given by the first address and port
pair of the "src_addr" parameter.</t>
<t>RTP and RTCP Packets SHOULD be sent from the corresponding
receiver port, i.e. RTCP packets from server should be sent from
the "src_addr" parameters second address port pair.</t>
</list></t>
</section>
<section title="AVPF/UDP">
<t>The RTP profile "Extended RTP Profile for RTCP-based Feedback
(RTP/AVPF)"<xref target="RFC4585"></xref> MAY be used as RTP
profiles in session using RTP. All that is defined for AVP SHALL
also apply for AVPF.</t>
<t>The usage of AVPF is indicated by the media initialization
protocol used. In the case of SDP it is indicated by media lines
(m=) containing the profile RTP/AVPF. That SDP MAY also contain
further AVPF related SDP attributes configuring the AVPF session
regarding reporting interval and feedback messages that shall be
used that SHALL be followed.</t>
</section>
<section title="SAVP/UDP">
<t>The RTP profile "The Secure Real-time Transport Protocol (SRTP)"
<xref target="RFC3711"></xref> is an RTP profile (SAVP) that MAY be
used in RTSP sessions using RTP. All that is defined for AVP SHALL
also apply for SAVP.</t>
<t>The usage of SRTP requires that a security association is
established. The RECOMMENDED mechanism for establishing that
security association is to use MIKEY with RTSP as defined in RFC
4567 <xref target="RFC4567"></xref>.</t>
</section>
<section title="SAVPF/UDP">
<t>The RTP profile "Extended Secure RTP Profile for RTCP-based
Feedback (RTP/SAVPF)" <xref target="RFC5124"></xref> is an RTP
profile (SAVPF) that MAY be used in RTSP sessions using RTP. All
that is defined for AVP SHALL also apply for SAVPF.</t>
<t>The usage of SRTP requires that a security association is
established. The RECOMMENDED mechanism for establishing that
security association is to use MIKEY<xref target="RFC3830"></xref>
with RTSP as defined in RFC 4567 <xref target="RFC4567"></xref>.</t>
</section>
<section title="RTCP usage with RTSP">
<t>RTCP has several usages when RTP is used for media transport as
explained below. Due to that RTCP SHALL be supported if an RTSP
agent handles RTP.</t>
<section title="Media synchronization">
<t>RTCP provides media synchronization and clock drift
compensation. The first is available from RTP-Info header to
accomplish the initial synchronization. But to be able to handle
any clockdrift between the media streams, RTCP is needed.</t>
</section>
<section title="RTSP Session keep-alive">
<t>RTCP traffic from the RTSP client to the RTSP server SHALL
function as keep-alive. Which requires an RTSP server supporting
RTP to use the received RTCP packets as indications that the
client desires the related RTSP session to be kept alive.</t>
</section>
<section title="Bit-rate adapation">
<t>RTCP Receiver reports and any additional feedback from the
client SHALL be used adapt the bit-rate used over the transport
for all cases when RTP is sent over UDP. A RTP sender without
reserved resources SHALL NOT use more than its fair share of the
available resources. This can be determined by comparing on short
to medium term (some seconds) the used bit-rate and adapt it so
that the RTP sender sends at a bit-rate comparable to what a TCP
sender would achieve on average over the same path.</t>
</section>
</section>
</section>
<section title="RTP over TCP">
<t>Transport of RTP over TCP can be done in two ways, over independent
TCP connections using RFC 4571 <xref target="RFC4571"></xref> or
interleaved in the RTSP control connection. In both cases the protocol
SHALL be "rtp" and the lower layer SHALL be TCP. The profile may be
any of the above specified ones; AVP, AVPF, SAVP or SAVPF.</t>
<section title="Interleaved RTP over TCP">
<t>The use of embedded (interleaved) binary data transported on the
RTSP connection is possible as specified in <xref
target="sec_binary"></xref>. When using this declared combination of
interleaved binary data the RTSP messages MUST be transported over
TCP. TLS may or may not be used.</t>
<t>One should however consider that this will result that all media
streams go through any proxy. Using independent TCP connections can
avoid that issue.</t>
</section>
<section anchor="sec_media-tcp-contrans"
title="RTP over independent TCP">
<t>In this Appendix, we describe the sending of RTP <xref
target="RFC3550"></xref> over lower transport layer TCP <xref
target="RFC0793"></xref> according to "Framing Real-time Transport
Protocol (RTP) and RTP Control Protocol (RTCP) Packets over
Connection-Oriented Transport" <xref target="RFC4571"></xref>. This
Appendix adapts the guidelines for using RTP over TCP within SIP/SDP
<xref target="RFC4145"></xref> to work with RTSP.</t>
<t>A client codes the support of RTP over independent TCP by
specifying an RTP/AVP/TCP transport option without an interleaved
parameter in the Transport line of a SETUP request. This transport
option MUST include the "unicast" parameter.</t>
<t>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 wishes to use RTP without RTCP, one port (or one address/port
pair) is specified by the dest_addr parameter. Ordering rules of
dest_addr ports follow the rules for RTP/AVP/UDP.</t>
<t>If the client wishes to play the active role in initiating the
TCP connection, it MAY set the "setup" parameter (See <xref
target="sec_Transport"></xref>) on the Transport line to be
"active", or it MAY omit the setup 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 discard port).</t>
<t>If the client wishes to play the passive role in TCP connection
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
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 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 for RTCP MUST be set to the TCP port number on which the
client is expecting to receive the RTCP stream connection.</t>
<t>If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a
server decides to accept this requested option, the 2xx reply MUST
contain a Transport option that specifies RTP/AVP/TCP (without using
the interleaved parameter, and with using the unicast parameter).
The dest_addr parameter value MUST be echoed from the parameter
value in the client request unless the destination address (only
port) was not provided in which can the server MAY include the
source address of the RTSP TCP connection with the port number
unchanged.</t>
<t>In addition, the server reply MUST set the setup parameter on the
Transport line, to indicate the role the server will play in the
connection setup. Permissible values are "active" (if a client set
"setup" to "passive" or "actpass") and "passive" (if a client set
"setup" to "active" or "actpass").</t>
<t>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 connection and (if the client requested an RTCP connection by
specifying two dest_addr ports or address/port pairs) and RTCP
connection. If a server sets "setup" to "active", the ports
specified in "src_addr" MUST be set to 9. The server MAY use the
"ssrc" parameter, following the guidance in <xref
target="sec_Transport"></xref>. Port ordering for src_addr follows
the rules for RTP/AVP/UDP.</t>
<t>For cases when servers have a public IP-address it is RECOMMENDED
that the server take the passive role and the client the active
role. This help in cases when the client is behind a NAT.</t>
<t>After sending (receiving) a 2xx reply for a SETUP method for a
non-interleaved RTP/AVP/TCP media stream, the active party SHOULD
initiate the TCP connection as soon as possible. The client SHALL
NOT send a PLAY request prior to the establishment of all the TCP
connections negotiated using SETUP for the session. In case the
server receives a PLAY request in a session that has not yet
established all the TCP connections, it SHALL respond using the 464
"Data Transport Not Ready Yet" (<xref target="sec_error464"></xref>)
error code.</t>
<t>Once the PLAY request for a media resource transported over
non-interleaved RTP/AVP/TCP occurs, media begins to flow from server
to client over the RTP TCP connection, and RTCP packets flow
bidirectionally over the RTCP TCP connection. As in the RTP/UDP
case, client to server traffic on the TCP port is unspecified by
this memo. The packets that travel on these connections SHALL be
framed using the protocol defined in <xref target="RFC4571"></xref>,
not by the framing defined for interleaving RTP over the RTSP
control connection defined in <xref target="sec_binary"></xref>.</t>
<t>A successful PAUSE request for a media being transported over
RTP/AVP/TCP pauses the flow of packets over the connections, without
closing the connections. A successful TEARDOWN request signals that
the TCP connections for RTP and RTCP are to be closed as soon as
possible.</t>
<t>Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may
be ambiguous in the following way: does the client wish to open up
new 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 SHOULD use the "connection" parameter (defined in <xref
target="sec_Transport"></xref>) on the Transport line to make its
intention clear in the regard (by setting "connection" to "new" if
new connections are needed, and by setting "connection" to
"existing" if the existing connections are to be used). After a 2xx
reply for a SETUP request for a new connection, parties should close
the pre-existing connections, after waiting a suitable period for
any stray RTP or RTCP packets to arrive.</t>
<t>Below, we rewrite part of the example media on demand example
shown in <xref target="sec-examples-mod-unicast"></xref> to use
RTP/AVP/TCP non-interleaved: <figure>
<artwork><![CDATA[
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"
setup=active;connection=new]]></artwork>
</figure><figure>
<artwork><![CDATA[ Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
setup=passive;connection=new;ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT
C->M: TCP Connection Establishment
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30-
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678
Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889
]]></artwork>
</figure></t>
</section>
<section title="Handling NPT Jumps in the RTP Media Layer">
<t>RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP
media layer<xref target="RFC3550"></xref>. Such control allows jumps
to be created in NPT timeline of the RTSP session. For example,
jumps in NPT can be caused by multiple ranges in the range specifier
of a PLAY request or through a "seek" opertaion on an RTSP session
which involves a PLAY, PAUSE, PLAY scenario where a new NPT is set
for the session. The media layer rendering the RTP stream should not
be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP
timestamps MUST be continuous and monotonic across jumps of NPT.</t>
<t><list style="hanging">
<t>We cannot assume that the RTSP client can communicate with
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 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 agent may believe later packets to be duplicates of
packets just played out.</t>
</list></t>
<t>As an example, assume a clock frequency of 8000 Hz, a
packetization interval of 100 ms and an initial sequence number and
timestamp of zero. <figure>
<artwork><![CDATA[
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: abcdefg
Range: npt=10-15
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: abcdefg
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
]]></artwork>
</figure></t>
<t>The ensuing RTP data stream is depicted below: <figure>
<artwork><![CDATA[
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
]]></artwork>
</figure></t>
<t>Immediately after the end of the play range, the client follows
up with a request to PLAY from a new NPT. <figure>
<artwork><![CDATA[
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Session: abcdefg
Range: npt=18-20
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 5
Session: abcdefg
Range: npt=18-20
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=50;rtptime=40100]]></artwork>
</figure></t>
<t>The ensuing RTP data stream is depicted below: <figure>
<artwork><![CDATA[
S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . .
S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
]]></artwork>
</figure></t>
<t>In this example, first, NPT 10 through 15 is played, then the
client request the server to skip ahead and play NPT 18 through 20.
The first segment is presented as RTP packets with sequence numbers
0 through 49 and timestamp 0 through 39,200. The second segment
consists of RTP packets with sequence number 50 through 69, with
timestamps 40,100 through 55,200. While there is a gap in the NPT,
there is no gap in the sequence number space of the RTP data
stream.</t>
<t>The RTP timestamp gap is present in the above example due to the
time it takes to perform the second play request, in this case 12.5
ms (100/8000). To avoid this gap in playback due to the time it
takes to perform RTSP requests, a PLAY request with multiple ranges
needs to be specified. That would result in the following example:
<figure>
<artwork><![CDATA[
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: abcdefg
Range: npt=10-15;npt=18-20]]></artwork>
</figure><figure>
<artwork><![CDATA[ User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: abcdefg
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
]]></artwork>
</figure></t>
<t>The ensuing RTP data stream is depicted below: <figure>
<artwork><![CDATA[
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . .
S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
]]></artwork>
</figure></t>
</section>
<section title="Handling RTP Timestamps after PAUSE">
<t>During a PAUSE / PLAY interaction in an RTSP session, the
duration of time for which the RTP transmission was halted MUST be
reflected in the RTP timestamp of each RTP stream. The duration can
be calculated for each RTP stream as the time elapsed from when the
last RTP packet was sent before the PAUSE request was received and
when the first RTP packet was sent after the subsequent PLAY request
was received. The duration includes all latency incurred and
processing time required to complete the request.</t>
<t><list style="hanging">
<t>The RTP RFC <xref target="RFC3550"></xref> states that: The
RTP timestamp for each unit[packet] would be related to the
wallclock time at which the unit becomes current on the virtual
presentation timeline.</t>
<t>In order to satisfy the requirements of <xref
target="RFC3550"></xref>, the RTP timestamp space needs to
increase continuously with real time. While this is not optimal
for stored media, it is required for RTP and RTCP to function as
intended. Using a continuous RTP timestamp space allows the same
timestamp model for both stored and live media and allows better
opportunity to integrate both types of media under a single
control.</t>
</list></t>
<t>As an example, assume a clock frequency of 8000 Hz, a
packetization interval of 100 ms and an initial sequence number and
timestamp of zero. <figure>
<artwork><![CDATA[
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: abcdefg
Range: npt=10-15]]></artwork>
</figure><figure>
<artwork><![CDATA[ User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: abcdefg
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
]]></artwork>
</figure></t>
<t>The ensuing RTP data stream is depicted below: <figure>
<artwork><![CDATA[
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
]]></artwork>
</figure></t>
<t>The client then sends a PAUSE request: <figure>
<artwork><![CDATA[
C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Session: abdcdefg
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 5
Session: abcdefg
Range: npt=10.4-15]]></artwork>
</figure></t>
<t>20 seconds elapse and then the client sends a PLAY request. In
addition the server requires 15 ms to process the request: <figure>
<artwork><![CDATA[
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6
Session: abcdefg
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: abcdefg
Range: npt=10.4-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=4;rtptime=164400]]></artwork>
</figure></t>
<t>The ensuing RTP data stream is depicted below: <figure>
<artwork><![CDATA[
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 = 6, rtptime = 166000, NPT time = 10.6s]]></artwork>
</figure></t>
<t>First, NPT 10 through 10.3 is played, then a PAUSE is received by
the server. After 20 seconds a PLAY is received by the server which
take 15ms to process. The duration of time for which the session was
paused is reflected in the RTP timestamp of the RTP packets sent
after this PLAY request.</t>
<t>A client can use the RTSP range header and RTP-Info header to map
NPT time of a presentation with the RTP timestamp.</t>
<t>Note: In RFC 2326 <xref target="RFC2326"></xref>, this matter was
not clearly defined and was misunderstood commonly. However for RTSP
2.0 it is expected that this will be handled correctly and no
exception handling will be required.</t>
</section>
<section title="RTSP / RTP Integration">
<t>For certain datatypes, tight integration between the RTSP layer
and the RTP layer will be necessary. This by no means precludes the
above restrictions. Combined RTSP/RTP media clients should use the
RTP-Info field to determine whether incoming RTP packets were sent
before or after a seek or before or after a PAUSE.</t>
</section>
<section title="Scaling with RTP">
<t>For scaling (see <xref target="sec_Scale"></xref>), RTP
timestamps should correspond to the playback timing. For example,
when playing video recorded at 30 frames/second at a scale of two
and speed (<xref target="sec_Speed"></xref>) of one, the server
would drop every second frame to maintain and deliver video packets
with the normal timestamp spacing of 3,000 per frame, but NPT would
increase by 1/15 second for each video frame.</t>
<t><list style="hanging">
<t>Note: The above scaling puts requirements on the media codec
or a media stream to support it. For example motion JPEG or
other non-predictive video coding can easier handle the above
example.</t>
</list></t>
</section>
<section title="Maintaining NPT synchronization with RTP timestamps">
<t>The client can maintain a correct display of NPT (Normal Play
Time) by noting the RTP timestamp value of the first packet arriving
after repositioning. The sequence parameter of the RTP-Info (<xref
target="sec_RTP-Info"></xref>) header provides the first sequence
number of the next segment.</t>
</section>
<section title="Continuous Audio">
<t>For continuous audio, the server SHOULD set the RTP marker bit at
the beginning of serving a new PLAY request or at jumps in timeline.
This allows the client to perform playout delay adaptation.</t>
</section>
<section title="Multiple Sources in an RTP Session">
<t>Note that more than one SSRC MAY be sent in the media stream. If
it happens all sources are expected to be rendered
simultaneously.</t>
</section>
<section title="Usage of SSRCs and the RTCP BYE Message During an RTSP Session">
<t>The RTCP BYE message indicates the end of use of a given SSRC. If
all sources leave an RTP session, it can, in most cases, be assumed
to have ended. Therefore, a client or server SHALL NOT send a RTCP
BYE message until it has finished using a SSRC. A server SHOULD keep
using a SSRC until the RTP session is terminated. Prolonging the use
of a SSRC allows the established synchronization context associated
with that SSRC to be used to synchronize subsequent PLAY requests
even if the PLAY response is late.</t>
<t>An SSRC collision with the SSRC that transmits media does also
have consequences, as it will force the media sender to change its
SSRC in accordance with the RTP specification<xref
target="RFC3550"></xref>. This will result in a loss of
synchronization context, and require any receiver to wait for RTCP
sender reports for all media requiring synchronization before being
able to play out synchronized. Due to these reasons a client joining
a session should take care to not select the same SSRC as the
server. Any SSRC signalled in the Transport header SHOULD be
avoided. A client detecting a collision prior to sending any RTP or
RTCP messages can also select a new SSRC.</t>
</section>
</section>
<section title="Future Additions">
<t>It is the intention that any future protocol or profile regarding
both for media delivery and lower transport should be easy to add to
RTSP. This section provides the necessary steps that needs to be
meet.</t>
<t>The following things needs to be considered when adding a new
protocol of profile for use with RTSP: <list hangIndent="3"
style="symbols">
<t>The protocol or profile needs to define a name tag representing
it. This tag is required to be a ABNF "token" to be possible to
use in the Transport header specification.</t>
<t>The useful combinations of protocol/profile/lower-layer needs
to be defined and for each combination declare the necessary
parameters to use in the Transport header.</t>
<t>For new media protocols the interaction with RTSP needs to be
addressed. One important factor will be the media
synchronization.</t>
</list></t>
<t>See the IANA section (<xref target="sec_IANA"></xref>) for
information how to register new attributes.</t>
</section>
</section>
<!-- title="Media Transport Alternatives" -->
<section anchor="sec_sdpusage"
title="Use of SDP for RTSP Session Descriptions">
<t>The Session Description Protocol (SDP, <xref
target="RFC4566"></xref>) may be used to describe streams or
presentations in RTSP. This description is typically returned in reply
to a DESCRIBE request on an URI from a server to a client, or received
via HTTP from a server to a client.</t>
<t>This appendix describes how an SDP file determines the operation of
an RTSP session. SDP as is provides no mechanism by which a client can
distinguish, without human guidance, between several media streams to be
rendered simultaneously and a set of alternatives (e.g., two audio
streams spoken in different languages). However the SDP extension
"Grouping of Media Lines in the Session Description Protocol (SDP)"
<xref target="RFC3388"></xref> may provide such functionality depending
on need. Also future grouping semantics may in the future be
developed.</t>
<section title="Definitions">
<t>The terms "session-level", "media-level" and other key/attribute
names and values used in this appendix are to be used as defined in
SDP (RFC 4566 <xref target="RFC4566"></xref>):</t>
<section anchor="sec_sdp-control-url" title="Control URI">
<t>The "a=control:" attribute is used to convey the control URI.
This attribute is used both for the session and media descriptions.
If used for individual media, it indicates the URI to be used for
controlling that particular media stream. If found at the session
level, the attribute indicates the URI for aggregate control
(presentation URI). The session level URI SHALL be different from
any media level URI. The presence of a session level control
attribute SHALL be interpreted as support for aggregated control.
The control attribute SHALL be present on media level unless the
presentation only contains a single media stream, in which case the
attribute MAY only be present on the session level.</t>
<t>ABNF for the attribute is defined in <xref
target="sec_sdp-syntax"></xref>.</t>
<t>Example: <figure>
<artwork><![CDATA[ a=control:rtsp://example.com/foo]]></artwork>
</figure></t>
<t>This attribute MAY contain either relative or absolute URIs,
following the rules and conventions set out in RFC 3986 <xref
target="RFC3986"></xref>. Implementations SHALL look for a base URI
in the following order: <list hangIndent="3" style="numbers">
<t>the RTSP Content-Base field;</t>
<t>the RTSP Content-Location field;</t>
<t>the RTSP Request-URI.</t>
</list> If this attribute contains only an asterisk (*), then the
URI SHALL be treated as if it were an empty embedded URI, and thus
inherit the entire base URI.</t>
<t>The URI handling for SDPs from container files need special
consideration. For example lets assume that a container file has the
URI: "rtsp://example.com/container.mp4". Lets further assume this
URI is the base URI, and that there is a absolute media level URI:
"rtsp://example.com/container.mp4/trackID=2". A relative media level
URI that resolves in accordance with RFC 3986 <xref
target="RFC3986"></xref> to the above given media URI is:
"container.mp4/trackID=2". It is usually not desirable to need to
include in or modify the SDP stored within the container file with
the server local name of the container file. 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 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 control URI
including the trailing slash, i.e.
"rtsp://example.com/container.mp4/".</t>
<t><list style="hanging">
<t>Note: The usage of TrackID in the above is not an
standardized form, but one example out of several similar
strings such as TrackID, Track_ID, StreamID that is used by
different server vendors to indicate a particular piece of media
inside a container file.</t>
</list></t>
</section>
<section title="Media Streams">
<t>The "m=" field is used to enumerate the streams. It is expected
that all the specified streams will be rendered with appropriate
synchronization. If the session is over multicast, the port number
indicated SHOULD be used for reception. The client MAY try to
override the destination port, through the Transport header. The
servers MAY allow this, the response will indicate if allowed or
not. If the session is unicast, the port number is the ones
RECOMMENDED by the server to the client, about which receiver ports
to use; the client MUST still include its receiver ports in its
SETUP request. The client MAY ignore this recommendation. If the
server has no preference, it SHOULD set the port number value to
zero.</t>
<t>The "m=" lines contain information about what transport protocol,
profile, and possibly lower-layer is to be used for the media
stream. The combination of transport, profile and lower layer, like
RTP/AVP/UDP needs to be defined for how to be used with RTSP. The
currently defined combinations are defined in <xref
target="sec_mediatran"></xref>, further combinations MAY be
specified.</t>
<t>Usage of grouping of media lines <xref target="RFC3388"></xref>
to determine which media lines should or should not be included in a
RTSP session is unspecified.</t>
<t>Example: <figure>
<artwork><![CDATA[ m=audio 0 RTP/AVP 31
]]></artwork>
</figure></t>
</section>
<section title="Payload Type(s)">
<t>The payload type(s) are specified in the "m=" line. In case the
payload type is a static payload type from RFC 3551 <xref
target="RFC3551"></xref>, no other information may be required. In
case it is a dynamic payload type, the media attribute "rtpmap" is
used to specify what the media is. The "encoding name" within the
"rtpmap" attribute may be one of those specified in RFC 3551
(Sections 5 and 6), or an MIME type registered with IANA, or an
experimental encoding as specified in SDP (RFC 4566 <xref
target="RFC4566"></xref>). Codec-specific parameters are not
specified in this field, but rather in the "fmtp" attribute
described below.</t>
</section>
<section title="Format-Specific Parameters">
<t>Format-specific parameters are conveyed using the "fmtp" media
attribute. The syntax of the "fmtp" attribute is specific to the
encoding(s) that the attribute refers to. Note that some of the
format specific parameters may be specified outside of the fmtp
parameters, like for example the "ptime" attribute for most audio
encodings.</t>
</section>
<section anchor="sec_sdp-direction"
title="Directionality of media stream">
<t>The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
provides instructions on which direction the media streams flow
within a session. When using RTSP the SDP can be delivered to a
client using either RTSP DESCRIBE or a number of RTSP external
methods, like HTTP, FTP, and email. Based on this the SDP applies to
how the RTSP client will see the complete session. Thus for media
streams delivered from the RTSP server to the client would be given
the "a=recvonly" attribute.</t>
<t>The direction attributes are not commonly used in SDPs for RTSP,
but may occur. "a=recvonly" in a SDP provided to the RTSP client
SHALL indicate that media delivery will only occur in the direction
from the RTSP server to the client. In SDP provided to the RTSP
client that lacks any of the directionality attributes (a=recvonly,
a=sendonly, a=sendrecv) SHALL behave as if the "a=recvonly"
attribute was received. Note that this overrules the normal default
rule defined in SDP<xref target="RFC4566"></xref>. The usage of
"a=sendonly" or "a=sendrecv" is not defined, nor is the
interpretation of SDP by other entities than the RTSP client.</t>
</section>
<section anchor="sec_sdp-range" title="Range of Presentation">
<t>The "a=range" attribute defines the total time range of the
stored session or an individual media. Non-seekable live sessions
can be indicated, while the length of live sessions can be deduced
from the "t" and "r" SDP parameters.</t>
<t>The attribute is both a session and a media level attribute. For
presentations that contains media streams of the same durations, the
range attribute SHOULD only be used at session-level. In case of
different length the range attribute MUST be given at media level
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
level values SHALL be used.</t>
<t>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. However that requires that the server accepts PLAY requests
within that range.</t>
<t>Servers SHALL take care to provide RTSP Range (see <xref
target="sec_Range"></xref>) values that are consistent with what is
presented in the SDP for the content. There are no reason for non
dynamic content, like media clips provided on demand to have
inconsistent values. Inconsistent values between the SDP and the
actual values for the content handled by the server is likely to
generate some failure, like 457 "Invalid Range", in case the client
uses PLAY requests with a Range header. In case the content is
dynamic in length and it is infeasible to provide a correct value in
the SDP the server is recommended to describe this as non-seekable
content (see below). The server MAY override that property in the
response to a PLAY request using the correct values in the Range
header.</t>
<t>The unit is specified first, followed by the value range. The
units and their values are as defined in <xref
target="sec_smpte"></xref>, <xref target="sec_npt"></xref> and <xref
target="sec_clock"></xref> and MAY be extended with further formats.
Any open ended range (start-), i.e. without stop range, is of
unspecified duration and SHALL be considered as non-seekable content
unless this property is overridden. Multiple instances carrying
different clock formats MAY be included at either session or media
level.</t>
<t>ABNF for the attribute is defined in <xref
target="sec_sdp-syntax"></xref>.</t>
<t>Examples: <figure>
<artwork><![CDATA[ a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203
Non seekable stream of unknown duration:
a=range:npt=0-
]]></artwork>
</figure></t>
</section>
<section title="Time of Availability">
<t>The "t=" field MUST contain suitable values for the start and
stop times for both aggregate and non-aggregate stream control. The
server SHOULD indicate a stop time value for which it guarantees the
description to be valid, and a start time that is equal to or before
the time at which the DESCRIBE request was received. It MAY also
indicate start and stop times of 0, meaning that the session is
always available.</t>
<t>For sessions that are of live type, i.e. specific start time,
unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD
be used to indicate the start time of the event. The stop time
SHOULD be given so that the live event will have ended at that time,
while still not be unnecessary long into the future.</t>
</section>
<section title="Connection Information">
<t>In SDP, the "c=" field contains the destination address for the
media stream. For on-demand unicast streams and some multicast
streams, the destination address MAY be specified by the client via
the SETUP request, thus overriding any specified address. To
identify streams without a fixed destination address, where the
client is required to specify a destination address, the "c=" field
SHOULD be set to a null value. For addresses of type "IP4", this
value SHALL be "0.0.0.0", and for type "IP6", this value SHALL be
"0:0:0:0:0:0:0:0", i.e. the unspecified address according to RFC
4291 <xref target="RFC4291"></xref>.</t>
</section>
<section anchor="sec_sdp-etag" title="Entity Tag">
<t>The optional "a=etag" attribute identifies a version of the
session description. It is opaque to the client. SETUP requests may
include this identifier in the If-Match field (see <xref
target="sec_If-Match"></xref>) to only allow session establishment
if this attribute value still corresponds to that of the current
description. The attribute value is opaque and may contain any
character allowed within SDP attribute values.</t>
<t>ABNF for the attribute is defined in <xref
target="sec_sdp-syntax"></xref>.</t>
<t>Example: <figure>
<artwork><![CDATA[ a=etag:158bb3e7c7fd62ce67f12b533f06b83a]]></artwork>
</figure></t>
<t><list style="hanging">
<t>One could argue that the "o=" field provides identical
functionality. However, it does so in a manner that would put
constraints on servers that need to support multiple session
description types other than SDP for the same piece of media
content.</t>
</list></t>
</section>
</section>
<section title="Aggregate Control Not Available">
<t>If a presentation does not support aggregate control no session
level "a=control:" attribute is specified. For a SDP with multiple
media sections specified, each section will have its own control URI
specified via the "a=control:" attribute.</t>
<t>Example: <figure>
<artwork><![CDATA[v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.56
s=I came from a web page
e=adm@example.com
c=IN IP4 0.0.0.0
t=0 0
m=video 8002 RTP/AVP 31
a=control:rtsp://audio.com/movie.aud
m=audio 8004 RTP/AVP 3
a=control:rtsp://video.com/movie.vid]]></artwork>
</figure></t>
<t>Note that the position of the control URI in the description
implies that the client establishes separate RTSP control sessions to
the servers audio.com and video.com.</t>
<t>It is recommended that an SDP file contains the complete media
initialization information even if it is delivered to the media client
through non-RTSP means. This is necessary as there is no mechanism to
indicate that the client should request more detailed media stream
information via DESCRIBE.</t>
</section>
<section title="Aggregate Control Available">
<t>In this scenario, the server has multiple streams that can be
controlled as a whole. In this case, there are both a media-level
"a=control:" attributes, which are used to specify the stream URIs,
and a session-level "a=control:" attribute which is used as the
Request-URI for aggregate control. If the media-level URI is relative,
it is resolved to absolute URIs according to <xref
target="sec_sdp-control-url"></xref> above.</t>
<t>Example: <figure>
<artwork><![CDATA[C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Base: rtsp://example.com/movie/
Content-Length: 228
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.211
s=I contain
i=<more info>
e=adm@example.com
c=IN IP4 0.0.0.0
t=0 0
a=control:*
m=video 8002 RTP/AVP 31
a=control:trackID=1
m=audio 8004 RTP/AVP 3
a=control:trackID=2]]></artwork>
</figure></t>
<t>In this example, the client is required to establish a single RTSP
session to the server, and uses the URIs
rtsp://example.com/movie/trackID=1 and
rtsp://example.com/movie/trackID=2 to set up the video and audio
streams, respectively. The URI rtsp://example.com/movie/, which is
resolved from the "*", controls the whole presentation (movie).</t>
<t>A client is not required to issues SETUP requests for all streams
within an aggregate object. Servers should allow the client to ask for
only a subset of the streams.</t>
</section>
<section title="RTSP external SDP delivery">
<t>There are some considerations that needs to be made when the
session description is delivered to client outside of RTSP, for
example in HTTP or email.</t>
<t>First of all the SDP needs to contain absolute URIs, relative will
in most cases not work as the delivery will not correctly forward the
base URI. And as SDP might be temporarily stored on file system before
being loaded into an RTSP capable client, thus if possible to
transport the base URI it still would need to be merged into the
file.</t>
<t>The writing of the SDP session availability information, i.e. "t="
and "r=", needs to be carefully considered. When the SDP is fetched by
the DESCRIBE method, the probability that it is valid is very high.
However the same are much less certain for SDPs distributed using
other methods. Therefore the publisher of the SDP should take care to
follow the recommendations about availability in the SDP specification
<xref target="RFC4566"></xref>.</t>
</section>
</section>
<!-- title="Use of SDP for RTSP Session Descriptions" -->
<section anchor="sec_text-parameters" title="Text format for Parameters">
<t>A resource of type "text/parameters" consists of either 1) a list of
parameters (for a query) or 2) a list of parameters and associated
values (for an response or setting of the parameter). Each entry of the
list is a single line of text. Parameters are separated from values by a
colon. The parameter name SHALL only use US-ASCII visable characters
while the values are UTF-8 text strings.</t>
<t>There exist a potential interoperability issue for this format. It
was named in RFC 2326 but never defined, even if used in examples that
hint at the syntax. This format matches the purpose and its syntax
supports the examples provided. However, it goes further by allowing
UTF-8 in the vaue part, thus usage of UTF-8 strings may not be
supported. However, as individual parameters are not defined, the using
application anyway needs to have out-of-band agreement or using
feature-tag to determine if the end-point supports the parameters.</t>
<t>The <xref target="RFC5234">ABNF</xref> grammar for "text/parameters"
content is:</t>
<t><figure>
<artwork><![CDATA[file = *((parameter / parameter-value) CRLF)
parameter = 1*visible-except-colon
parameter-value = parameter *WSP ":" value
visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":"
value = *(TEXT-UTF8char / WSP)
TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF
WSP = <See RFC 5234> ; Space or HTAB
VCHAR = <See RFC 5234>
CRLF = <See RFC 5234>]]></artwork>
</figure></t>
<t></t>
</section>
<!--title="Text format for Parameters-->
<section anchor="sec_unreliable"
title="Requirements for Unreliable Transport of RTSP">
<t>This section provides anyone intending to define how to transport of
RTSP messages over a unreliable transport protocol with some information
learned by the attempt in RFC 2326 <xref target="RFC2326"></xref>. RFC
2326 define both an URI scheme and some basic functionality for
transport of RTSP messages over UDP, however it was not sufficient for
reliable usage and successful interoperability.</t>
<t>The RTSP scheme defined for unreliable transport of RTSP messages was
"rtspu". It has been reserved by this specification as at least one
commercial implementation exist, thus avoiding any collisions in the
name space.</t>
<t>The following considerations should exist for operation of RTSP over
an unreliable transport protocol: <list hangIndent="3" style="symbols">
<t>Request shall be acknowledged by the receiver. If there is no
acknowledgement, the sender may resend the same message after a
timeout of one round-trip time (RTT). Any retransmissions due to
lack of acknowledgement must carry the same sequence number as the
original request.</t>
<t>The round-trip time can be estimated as in TCP (RFC 1123) <xref
target="RFC1123"></xref>, with an initial round-trip value of 500
ms. An implementation may cache the last RTT measurement as the
initial value for future connections.</t>
<t>If RTSP is used over a small-RTT LAN, standard procedures for
optimizing initial TCP round trip estimates, such as those used in
T/TCP (RFC 1644) <xref target="RFC1644"></xref>, can be
beneficial.</t>
<t>The Timestamp header (<xref target="sec_Timestamp"></xref>) is
used to avoid the retransmission ambiguity problem <!--<xref target="Stev94:TCP"/>-->
XXY Need ref for Stev94:TCP and obviates the need for Karn's
algorithm.</t>
<t>The registered default port for RTSP over UDP for the server is
554.</t>
<t>RTSP messages can be carried over any lower-layer transport
protocol that is 8-bit clean.</t>
<t>RTSP messages are vulnerable to bit errors and should not be
subjected to them.</t>
<t>Source authentication, or at least validation that RTSP messages
comes from the same entity becomes extremely important, as session
hijacking may be substantially easier for RTSP message transport
using an unreliable protocol like UDP than for TCP.</t>
</list></t>
<t>There exist two RTSP headers thats primarily are intended for being
used by the unreliable handling of RTSP messages and which will be
maintained: <list hangIndent="3" style="symbols">
<t>[CSeq] See <xref target="sec_CSeq"></xref></t>
<t>[Timestamp] See <xref target="sec_Timestamp"></xref></t>
</list></t>
</section>
<!-- title="Requirements for Unreliable Transport of RTSP"> -->
<section anchor="sec_backwards"
title="Backwards Compatibility Considerations">
<t>This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 <xref
target="RFC2326"></xref>. Note that there exist no requirement to
implement RTSP 1.0, in fact we recommend against it as it is difficult
to do in an interoperable way.</t>
<t>A server implementing RTSP/2.0 MUST include a RTSP-Version of
RTSP/2.0 in all responses to requests containing RTSP-Version RTSP/2.0.
If a server receives a RTSP/1.0 request, it MAY respond with a RTSP/1.0
response if it chooses to support RFC 2326. If the server chooses not to
support RFC 2326, it SHOULD respond with a 505 (RTSP Version not
supported) status code. A server MUST NOT respond to a RTSP-Version
RTSP/1.0 request with a RTSP-Version RTSP/2.0 response.</t>
<t>Clients implementing RTSP/2.0 MAY use an OPTIONS request with a
RTSP-Version of 2.0 to determine whether a server supports RTSP/2.0. If
the server responds with either a RTSP-Version of 1.0 or a status code
of 505 (RTSP Version not supported), the client will have to use
RTSP/1.0 requests if it chooses to support RFC 2326.</t>
<section anchor="sec_back-play" title="Play Request in Play mode">
<t>The behavior in the server when a Play is received in Play mode has
changed (<xref target="sec_PLAY"></xref>). In RFC 2326, the new PLAY
request would be queued until the current Play completed. Any new PLAY
request now take effect immediately replacing the previous
request.</t>
</section>
<section anchor="sec_back-persistent-connection"
title="Using Persistent Connections">
<t>Some server implementations of RFC 2326 maintain a one-to-one
relationship between a connection and an RTSP session. Such
implementations require clients to use a persistent connection to
communicate with the server and when a client closes its connection,
the server may remove the RTSP session. This is worth noting if a RTSP
2.0 client also supporting 1.0 connects to a 1.0 server.</t>
</section>
</section>
<!-- title="Backwards Compatibility Considerations" -->
<section anchor="sec_open" title="Open Issues">
<t>This section contains a list of open issues that still needs to be
resolved. However also any open issues in the bug tracker at
http://rtspspec.sourceforge.net should also be considered. <list
hangIndent="3" style="numbers">
<t>Should the SMPTE range format be updated to support the 50 and 60
frames per second modes?</t>
<t>Should we define a recommended format for error message
bodies?</t>
<t>Today there is no recommended or required format for 300 response
entities containing URI lists. Should one be defined?</t>
<t>Should the dest_addr parameter in the Transport header in
responses include the destination used by the server?</t>
<t>Should a IPv6 multicast scope parameter for the Transport header
be defined? This would be similar to TTL.</t>
<t>The Expires header (<xref target="sec_Expires"></xref> contains
the below paragraph: <vspace blankLines="1" /> Expires header field
with a date value of some time in the future on a media stream that
otherwise would by default be non- cacheable indicates that the
media stream is cacheable, unless indicated otherwise by a
Cache-Control header field (<xref
target="sec_Cache-Control"></xref>). <vspace blankLines="1" /> Is
there any purpose for this in RTSP, or could we remove this
statement and instead rely on the Cache-Control header?</t>
<t>Should proxies strip out the credentials for themselves when
forwarding messages with Accept-Credentials?</t>
<t>Is Session ID combined with TLS a sufficient mechanism to prevent
hijacking?</t>
<t>Move to start TLS mechanism like the one defined in RFC 2817?</t>
<t>Look into the GRID communities proxy-certs and see how this
relates to the current TLS proxy solution.</t>
<t>Resolve Eric Rescorlas security comments on the Proxy TLS
solution: <list style="numbers">
<t>There doesn't seem to be any way to communicate your cipher
suite preferences.</t>
<t>I don't see how certificate-based client authentication
works. Is it supposed to?</t>
<t>You need to provide the entire cert chain in
Connection-Credentials, not just the certificate.</t>
</list></t>
<t>Consider to switch to SHA256 instead of SHA1 for the digest over
the DER encoded certs.</t>
<t>Resolve the following Stephen Farrel issue: "C. I don't
understand how the client-side proxies can be expected to know
enough about proxies existing toward the server. If they don't then
I'm not sure how they can be expected to make any decision that's
better than would be the case were policy to be dealt with solely on
a hop-by-hop basis. Maybe I'm missing something that can provide
that information?"</t>
<t>Resolve the following Stephen Farrel issue: "D. The "User" policy
model is that a client presents acceptable name/URIs and digests to
the proxy. TLS doesn't really provide a way for that proxy, as a
client, to ask the server for the "right" certificate, so I suspect
there's a gap here that'll be hard to fill. (If the client imposed a
constraint as to the root-CA that had to be used then that'd map to
the next TLS connection, but maybe it'd be too coarse-grained?)"</t>
</list></t>
<t></t>
</section>
<!-- title="Open Issues" -->
<section anchor="sec_changes" title="Changes">
<t>Compared to RTSP 1.0 (RFC 2326), the below changes has been made when
defining RTSP 2.0. Note that this list does not reflect minor changes in
wording or correction of typographical errors. <list hangIndent="3"
style="symbols">
<t>The section on minimal implementation was deleted without
substitution.</t>
<t>The Transport header has been changed in the following way: <list
style="symbols">
<t>The ABNF has been changed to define that extensions are
possible, and that unknown extension parameters are to be
ignored.</t>
<t>To prevent backwards compatibility issues, any extension or
new parameter requires the usage of a feature-tag combined with
the Require header.</t>
<t>Syntax unclarities with the Mode parameter has been
resolved.</t>
<t>Syntax error with ";" for multicast and unicast has been
resolved.</t>
<t>Two new addressing parameters has been defined, src_addr and
dest_addr. These replaces the parameters "port", "client_port",
"server_port", "destination", "source".</t>
<t>Support for IPv6 explicit addresses in all address fields has
been included.</t>
<t>To handle URI definitions that contain ";" or "," a quoted
URI format has been introduced and is required.</t>
<t>Defined IANA registries for the transport headers parameters,
transport-protocol, profile, lower-transport, and mode.</t>
<t>The transport headers interleaved parameter's text was made
more strict and use formal requirements levels. It was also
clarified that the interleaved channels are symmetric and that
it is the server that sets the channel numbers.</t>
<t>It has been clarified that the client can't request of the
server to use a certain RTP SSRC, using a request with the
transport parameter SSRC.</t>
<t>Syntax definition for SSRC has been clarified to require
8HEX. It has also been extend to allow multiple values for
clients supporting this version.</t>
<t>Clarified the text on the transport headers "dest_addr"
parameters regarding what security precautions the server is
required to perform.</t>
</list></t>
<t>The Range formats has been changed in the following way: <list
style="symbols">
<t>The NPT format has been given a initial NPT identifier that
must now be used.</t>
<t>All formats now support initial open ended formats of type
"npt=-10".</t>
</list></t>
<t>RTSP message handling has been changed in the following way:
<list style="symbols">
<t>RTSP messages now uses URIs rather then URLs.</t>
<t>It has been clarified that a 4xx message due to missing CSeq
header shall be returned without a CSeq header.</t>
<t>Rules for how to handle timing out RTSP messages has been
added.</t>
<t>Extended Pipelining rules allowing for quick session
startup.</t>
</list></t>
<t>The HTTP references has been updated to RFC 2616 and RFC 2617.
This has resulted in that the Public, and the Content-Base header
needed to be defined in the RTSP specification. Known effects on
RTSP due to HTTP clarifications: <list style="symbols">
<t>Content-Encoding header can include encoding of type
"identity".</t>
</list></t>
<t>The state machine section has completely been rewritten. It
includes now more details and are also more clear about the model
used.</t>
<t>A IANA section has been included with contains a number of
registries and their rules. This will allow us to use IANA to keep
track of RTSP extensions.</t>
<t>Than transport of RTSP messages has seen the following changes:
<list style="symbols">
<t>The use of UDP for RTSP message transport has been deprecated
due to missing interest and to broken specification.</t>
<t>The rules for how TCP connections is to be handled has been
clarified. Now it is made clear that servers should not close
the TCP connection unless they have been unused for significant
time.</t>
<t>Strong recommendations why server and clients should use
persistent connections has also been added.</t>
<t>There is now a requirement on the servers to handle
non-persistent connections as this provides fault tolerance.</t>
<t>Added wording on the usage of Connection:Close for RTSP.</t>
<t>specified usage of TLS for RTSP messages, including a scheme
to approve a proxies TLS connection to the next hop.</t>
</list></t>
<t>The following header related changes have been made: <list
style="symbols">
<t>Accept-Ranges response header is added. This header clarifies
which range formats that can be used for a resource.</t>
<t>Changed the Range header to allow multiple ranges for
creating editing list.</t>
<t>Fixed the missing definitions for the Cache-Control header.
Also added to the syntax definition the missing delta-seconds
for max-stale and min-fresh parameters.</t>
<t>Put requirement on CSeq header that the value is increased by
one for each new RTSP request. A Recommendation to start at 1
has also been added.</t>
<t>Added requirement that the Date header must be used for all
messages with entity and the Server should always include
it.</t>
<t>Removed possibility of using Range header with Scale header
to indicate when it is to be activated, since it can't work as
defined. Also added rule that lack of Scale header in response
indicates lack of support for the header. Feature-tags for
scaled playback has been defined.</t>
<t>The Speed header must now be responded to indicate support
and the actual speed going to be used. A feature-tag is defined.
Notes on congestion control was also added.</t>
<t>The Supported header was borrowed from SIP to help with the
feature negotiation in RTSP.</t>
<t>Clarified that the Timestamp header can be used to resolve
retransmission ambiguities.</t>
<t>The Session header text has been expanded with a explanation
on keep alive and which methods to use. SET_PARAMETER is now
recommended to use if only keep-alive within RTSP is
desired.</t>
<t>It has been clarified how the Range header formats is used to
indicate pause points in the PAUSE response.</t>
<t>Clarified that RTP-Info URIs that are relative, uses the
Request-URI as base URI. Also clarified that used URI must be
that one that was used in the SETUP request. They are now also
required to be quoted. The header also expresses the SSRC for
the provided RTP timestamp and sequence number values.</t>
<t>Added text that requires the Range to always be present in
PLAY responses. Clarified what should be sent in case of live
streams.</t>
<t>The headers table has been updated using a structured
borrowed from SIP. Those tables carries much more information
and should provide a good overview of the available headers.</t>
<t>It has been is clarified that any message with a message body
is required to have a Content-Length header. This was the case
in RFC 2326 but could be misinterpreted.</t>
<t>To resolve functionality around ETag. The ETag and
If-None-Match header has been added from HTTP with necessary
clarification in regards to RTSP operation.</t>
<t>Imported the Public header from HTTP RFC 2068 <xref
target="RFC2068"></xref> since it has been removed from HTTP due
to lack of use. Public is used quite frequently in RTSP.</t>
<t>Clarified rules for populating the Public header so that it
is an intersection of the capabilities of all the RTSP agents in
a chain.</t>
<t>Added the Media-Range header for listing the current
availability of the media range.</t>
<t>Added the Notify-Reason header for giving the reason when
sending PLAY_NOTIFY requests.</t>
</list></t>
<t>The Protocol Syntax has been changed in the following way: <list
style="symbols">
<t>All BNF definitions are updated according to the rules
defined in RFC 5234 <xref target="RFC5234"></xref> and has been
gathered in a separate <xref target="sec_syntax"></xref>.</t>
<t>The BNF for the User-Agent and Server headers has been
corrected so now only the description is in the HTTP
specification.</t>
<t>Some definitions in the introduction regarding the RTSP
session has been changed.</t>
<t>The protocol has been made fully IPv6 capable. Certain of the
functionality, like using explicit IPv6 addresses in fields
requires that the protocol support this updated
specification.</t>
<t>Added a fragment part to the RTSP URI. This seem to be
indicated by the note below the definition however it was not
part of the BNF.</t>
<t>The CHAR rule has been changed to exclude NULL.</t>
</list></t>
<t>The Status codes has been changed in the following way: <list
style="symbols">
<t>The use of status code 303 "See Other" has been deprecated as
it does not make sense to use in RTSP.</t>
<t>When sending response 451 and 458 the response body should
contain the offending parameters.</t>
<t>Clarification on when a 3rr redirect status code can be
received has been added. This includes receiving 3rr as a result
of request within a established session. This provides
clarification to a previous unspecified behavior.</t>
<t>Removed the 201 (Created) and 250 (Low On Storage Space)
status codes as they are only relevant to recording, which is
deprecated.</t>
</list></t>
<t>The following functionality has been deprecated from the
protocol: <list style="symbols">
<t>The use of Queued Play.</t>
<t>The use of PLAY method for keep-alive in play state.</t>
<t>The RECORD and ANNOUNCE methods and all related
functionality. Some of the syntax has been removed.</t>
<t>The possibility to use timed execution of methods with the
time parameter in the Range header.</t>
<t>The description on how rtspu works is not part of the core
specification and will require external description. Only that
it exist is defined here and some requirements for the the
transport is provided.</t>
</list></t>
<t>The following changes has been made in relation to methods: <list
style="symbols">
<t>The OPTIONS method has been clarified with regards to the use
of the Public and Allow headers.</t>
<t>The RECORD and ANNOUNCE methods are removed as they are
lacking implementation and not considered necessary in the core
specification. Any work on these methods should be done as a
extension document to RTSP.</t>
<t>Added text clarifying the usage of SET_PARAMETER for
keep-alive and usage without any body.</t>
<t>PLAY method is now allowed to be pipelined with the
pipelining of one or more SETUP requests following the initial
that generates the session for aggregated control.</t>
</list></t>
<t>Wrote a new section about how to setup different media transport
alternatives and their profiles, and lower layer protocols. This
resulted that the appendix on RTP interaction was moved there
instead in the part describing RTP. The section also includes
guidelines what to think of when writing usage guidelines for new
protocols and profiles.</t>
<t>Setup and usage of independent TCP connections for transport of
RTP has been specified.</t>
<t>Added a new section describing the available mechanisms to
determine if functionality is supported, called "Capability
Handling". Renamed option-tags to feature-tags.</t>
<t>Added a contributors section with people who have contributed
actual text to the specification.</t>
<t>Added a section Use Cases that describes the major use cases for
RTSP.</t>
<t>Clarified the usage of a=range and how to indicate live content
that are not seekable with this header.</t>
<t>Text specifying the special behavior of PLAY for live
content.</t>
<t>Added a new method PLAY_NOTIFY. This method is used by the RTSP
server to asynchronously notify clients about session changes.</t>
</list></t>
</section>
<!-- title="Changes" -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in <xref
target="RFC2326"></xref>. The authors of this RFC are Henning
Schulzrinne, Anup Rao, and Robert Lanphier.</t>
<t>Both RTSP version 1.0 and RTSP versio 2.0 borrow format and
descriptions from HTTP/1.1.</t>
<t>This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already mentioned,
the following individuals have contributed to this specification:</t>
<t>Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning,
Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari,
Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V.
Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt,
John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Anders Klemets, Ruth
Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Thomas
Marshall, Rob McCool, David Oran, Joerg Ott, Maria Papadopouli, Sujal
Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Igor Plotnikov,
Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith,
Alexander Sokolsky, Dale Stammen, John Francis Stracke, Maureen Chesire,
David Walker, Geetha Srikantan, Stephan Wenger, Pekka Pessi, Jae-Hwan
Kim, Holger Schmidt, Stephen Farrell, Xavier Marjou, Joe Pallas and Mela
Martti.</t>
<section anchor="sec_contributors" title="Contributors">
<t>The following people have made written contributions that were
included in the specification: <list hangIndent="3" style="symbols">
<t>Tom Marshall contributed text on the usage of 3rr status
codes.</t>
<t>Thomas Zheng contributed text on the usage of the Range in PLAY
responses.</t>
<t>Sean Sheedy contributed text on the timeout behavior of RTSP
messages and connections, and the 463 status code.</t>
<t>Fredrik Lindholm contributed text about the RTSP security
framework.</t>
<t>John Lazzaro contributed the text for RTP over Independent
TCP.</t>
<t>Aravind Narasimhan contributed by rewriting <xref
target="sec_mediatran">Media Transport Alternatives</xref> and
editorial improvements on a number of places in the
specification.</t>
</list></t>
</section>
<!-- title="Contributors" -->
</section>
<!-- title="Acknowledgements" -->
<section anchor="RFCEditorConsideration" title="RFC Editor Consideration">
<t>Please replace RFC XXXX with the RFC number this specification
recieves.</t>
<t>Please replace RFC YYYY with the RFC number that SAVPF <xref
target="RFC5124"></xref> receives.</t>
</section>
<!-- title="RFC Editor Consideration" -->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 23:16:29 |