draft-ietf-mmusic-rtsp-07.txt   draft-ietf-mmusic-rtsp-08.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft H. Schulzrinne, A. Rao, R. Lanphier Internet Draft H. Schulzrinne, A. Rao, R. Lanphier
draft-ietf-mmusic-rtsp-07.txt Columbia U./Netscape/RealNetworks draft-ietf-mmusic-rtsp-08.txt Columbia U./Netscape/RealNetworks
January 7, 1998 Expires: July 7, 1998 January 15, 1998 Expires: July 15, 1998
Real Time Streaming Protocol (RTSP) Real Time Streaming Protocol (RTSP)
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at line 208 skipping to change at line 208
o C.1.8 Entity Tag o C.1.8 Entity Tag
+ C.2 Aggregate Control Not Available + C.2 Aggregate Control Not Available
+ C.3 Aggregate Control Available + C.3 Aggregate Control Available
* D Minimal RTSP implementation * D Minimal RTSP implementation
+ D.1 Client + D.1 Client
o D.1.1 Basic Playback o D.1.1 Basic Playback
o D.1.2 Authentication-enabled o D.1.2 Authentication-enabled
+ D.2 Server + D.2 Server
o D.2.1 Basic Playback o D.2.1 Basic Playback
o D.2.2 Authentication-enabled o D.2.2 Authentication-enabled
* E Changes * E Author Addresses
* F Author Addresses * F Acknowledgements
* G Acknowledgements
* References * References
1 Introduction 1 Introduction
1.1 Purpose 1.1 Purpose
The Real-Time Streaming Protocol (RTSP) establishes and controls The Real-Time Streaming Protocol (RTSP) establishes and controls
either a single or several time-synchronized streams of continuous either a single or several time-synchronized streams of continuous
media such as audio and video. It does not typically deliver the media such as audio and video. It does not typically deliver the
continuous streams itself, although interleaving of the continuous continuous streams itself, although interleaving of the continuous
skipping to change at line 237 skipping to change at line 236
presentation description. presentation description.
There is no notion of an RTSP connection; instead, a server maintains There is no notion of an RTSP connection; instead, a server maintains
a session labeled by an identifier. An RTSP session is in no way tied a session labeled by an identifier. An RTSP session is in no way tied
to a transport-level connection such as a TCP connection. During an to a transport-level connection such as a TCP connection. During an
RTSP session, an RTSP client may open and close many reliable RTSP session, an RTSP client may open and close many reliable
transport connections to the server to issue RTSP requests. transport connections to the server to issue RTSP requests.
Alternatively, it may use a connectionless transport protocol such as Alternatively, it may use a connectionless transport protocol such as
UDP. UDP.
H. Schulzrinne, A. Rao, R. Lanphier Page 5
The streams controlled by RTSP may use RTP [1], but the operation of The streams controlled by RTSP may use RTP [1], but the operation of
RTSP does not depend on the transport mechanism used to carry RTSP does not depend on the transport mechanism used to carry
continuous media. continuous media.
H. Schulzrinne, A. Rao, R. Lanphier Page 5
The protocol is intentionally similar in syntax and operation to The protocol is intentionally similar in syntax and operation to
HTTP/1.1 so that extension mechanisms to HTTP can in most cases also HTTP/1.1 [2] so that extension mechanisms to HTTP can in most cases
be added to RTSP. However, RTSP differs in a number of important also be added to RTSP. However, RTSP differs in a number of important
aspects from HTTP: aspects from HTTP:
* RTSP introduces a number of new methods and has a different * RTSP introduces a number of new methods and has a different
protocol identifier. protocol identifier.
* An RTSP server needs to maintain state by default in almost all * An RTSP server needs to maintain state by default in almost all
cases, as opposed to the stateless nature of HTTP. cases, as opposed to the stateless nature of HTTP.
* Both an RTSP server and client can issue requests. * Both an RTSP server and client can issue requests.
* Data is carried out-of-band by a different protocol. (There is an * Data is carried out-of-band by a different protocol. (There is an
exception to this.) exception to this.)
* RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1,
consistent with current HTML internationalization efforts [2]. consistent with current HTML internationalization efforts [3].
* The Request-URI always contains the absolute URI. Because of * The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1 carries backward compatibility with a historical blunder, HTTP/1.1 [2]
only the absolute path in the request and puts the host name in a carries only the absolute path in the request and puts the host
separate header field. name in a separate header field.
This makes ``virtual hosting'' easier, where a single host with one This makes ``virtual hosting'' easier, where a single host with one
IP address hosts several document trees. IP address hosts several document trees.
The protocol supports the following operations: The protocol supports the following operations:
Retrieval of media from media server: Retrieval of media from media server:
The client can request a presentation description via HTTP or The client can request a presentation description via HTTP or
some other method. If the presentation is being multicast, the some other method. If the presentation is being multicast, the
presentation description contains the multicast addresses and presentation description contains the multicast addresses and
skipping to change at line 282 skipping to change at line 281
provides the destination for security reasons. provides the destination for security reasons.
Invitation of a media server to a conference: Invitation of a media server to a conference:
A media server can be ``invited'' to join an existing A media server can be ``invited'' to join an existing
conference, either to play back media into the presentation or conference, either to play back media into the presentation or
to record all or a subset of the media in a presentation. This to record all or a subset of the media in a presentation. This
mode is useful for distributed teaching applications. Several mode is useful for distributed teaching applications. Several
parties in the conference may take turns ``pushing the remote parties in the conference may take turns ``pushing the remote
control buttons''. control buttons''.
H. Schulzrinne, A. Rao, R. Lanphier Page 6
Addition of media to an existing presentation: Addition of media to an existing presentation:
Particularly for live presentations, it is useful if the server Particularly for live presentations, it is useful if the server
can tell the client about additional media becoming available. can tell the client about additional media becoming available.
RTSP requests may be handled by proxies, tunnels and caches as in RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1. HTTP/1.1 [2].
H. Schulzrinne, A. Rao, R. Lanphier Page 6
1.2 Requirements 1.2 Requirements
The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and
``OPTIONAL'' in this document are to be interpreted as described in ``OPTIONAL'' in this document are to be interpreted as described in
RFC 2119 [3]. RFC 2119 [4].
1.3 Terminology 1.3 Terminology
Some of the terminology has been adopted from HTTP/1.1 [4]. Terms not Some of the terminology has been adopted from HTTP/1.1 [2]. Terms not
listed here are defined as in HTTP/1.1. listed here are defined as in HTTP/1.1.
Aggregate control: Aggregate control:
The control of the multiple streams using a single timeline by The control of the multiple streams using a single timeline by
the server. For audio/video feeds, this means that the client the server. For audio/video feeds, this means that the client
may issue a single play or pause message to control both the may issue a single play or pause message to control both the
audio and video feeds. audio and video feeds.
Conference: Conference:
a multiparty, multimedia presentation, where ``multi'' implies a multiparty, multimedia presentation, where ``multi'' implies
skipping to change at line 326 skipping to change at line 326
Connection: Connection:
A transport layer virtual circuit established between two A transport layer virtual circuit established between two
programs for the purpose of communication. programs for the purpose of communication.
Container file: Container file:
A file which may contain multiple media streams which often A file which may contain multiple media streams which often
comprise a presentation when played together. RTSP servers may comprise a presentation when played together. RTSP servers may
offer aggregate control on these files, though the concept of a offer aggregate control on these files, though the concept of a
container file is not embedded in the protocol. container file is not embedded in the protocol.
H. Schulzrinne, A. Rao, R. Lanphier Page 7
Continuous media: Continuous media:
Data where there is a timing relationship between source and Data where there is a timing relationship between source and
sink; that is, the sink must reproduce the timing relationship sink; that is, the sink must reproduce the timing relationship
that existed at the source. The most common examples of that existed at the source. The most common examples of
continuous media are audio and motion video. Continuous media continuous media are audio and motion video. Continuous media
can be real-time (interactive), where there is a ``tight'' can be real-time (interactive), where there is a ``tight''
timing relationship between source and sink, or streaming timing relationship between source and sink, or streaming
(playback), where the relationship is less strict. (playback), where the relationship is less strict.
H. Schulzrinne, A. Rao, R. Lanphier Page 7
Entity: Entity:
The information transferred as the payload of a request or The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of response. An entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, entity-header fields and content in the form of an entity-body,
as described in Section 8. as described in Section 8.
Media initialization: Media initialization:
Datatype/codec specific initialization. This includes such Datatype/codec specific initialization. This includes such
things as clockrates, color tables, etc. Any things as clockrates, color tables, etc. Any
transport-independent information which is required by a client transport-independent information which is required by a client
skipping to change at line 370 skipping to change at line 370
Media server indirection: Media server indirection:
Redirection of a media client to a different media server. Redirection of a media client to a different media server.
(Media) stream: (Media) stream:
A single media instance, e.g., an audio stream or a video A single media instance, e.g., an audio stream or a video
stream as well as a single whiteboard or shared application stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. This is packets created by a source within an RTP session. This is
equivalent to the definition of a DSM-CC stream([5]). equivalent to the definition of a DSM-CC stream([5]).
H. Schulzrinne, A. Rao, R. Lanphier Page 8
Message: Message:
The basic unit of RTSP communication, consisting of a The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 15 and transmitted via a connection or a connectionless Section 15 and transmitted via a connection or a connectionless
protocol. protocol.
Participant: Participant:
Member of a conference. A participant may be a machine, e.g., a Member of a conference. A participant may be a machine, e.g., a
media record or playback server. media record or playback server.
H. Schulzrinne, A. Rao, R. Lanphier Page 8
Presentation: Presentation:
A set of one or more streams presented to the client as a A set of one or more streams presented to the client as a
complete media feed, using a presentation description as complete media feed, using a presentation description as
defined below. In most cases in the RTSP context, this implies defined below. In most cases in the RTSP context, this implies
aggregate control of those streams, but does not have to. aggregate control of those streams, but does not have to.
Presentation description: Presentation description:
A presentation description contains information about one or A presentation description contains information about one or
more media streams within a presentation, such as the set of more media streams within a presentation, such as the set of
encodings, network addresses and information about the content. encodings, network addresses and information about the content.
Other IETF protocols such as SDP (RFC XXXX) use the term Other IETF protocols such as SDP (RFC XXXX [6]) use the term
``session'' for a live presentation. The presentation ``session'' for a live presentation. The presentation
description may take several different formats, including but description may take several different formats, including but
not limited to the session description format SDP. not limited to the session description format SDP.
Response: Response:
An RTSP response. If an HTTP response is meant, that is An RTSP response. If an HTTP response is meant, that is
indicated explicitly. indicated explicitly.
Request: Request:
An RTSP request. If an HTTP request is meant, that is indicated An RTSP request. If an HTTP request is meant, that is indicated
skipping to change at line 415 skipping to change at line 415
A complete RTSP ``transaction'', e.g., the viewing of a movie. A complete RTSP ``transaction'', e.g., the viewing of a movie.
A session typically consists of a client setting up a transport A session typically consists of a client setting up a transport
mechanism for the continuous media stream (SETUP), starting the mechanism for the continuous media stream (SETUP), starting the
stream with PLAY or RECORD, and closing the stream with stream with PLAY or RECORD, and closing the stream with
TEARDOWN. TEARDOWN.
Transport initialization: Transport initialization:
The negotiation of transport information (e.g., port numbers, The negotiation of transport information (e.g., port numbers,
transport protocols) between the client and the server. transport protocols) between the client and the server.
H. Schulzrinne, A. Rao, R. Lanphier Page 9
1.4 Protocol Properties 1.4 Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: Extendable:
New methods and parameters can be easily added to RTSP. New methods and parameters can be easily added to RTSP.
Easy to parse: Easy to parse:
RTSP can be parsed by standard HTTP or MIME parsers. RTSP can be parsed by standard HTTP or MIME parsers.
H. Schulzrinne, A. Rao, R. Lanphier Page 9
Secure: Secure:
RTSP re-uses web security mechanisms, either at the transport RTSP re-uses web security mechanisms, either at the transport
level (TLS, RFC XXXX) or within the protocol itself. All HTTP level (TLS, RFC XXXX [7]) or within the protocol itself. All
authentication mechanisms such as basic [4, Section 11.1] and HTTP authentication mechanisms such as basic (RFC 2068 [2,
digest authentication [6] are directly applicable. Section 11.1]) and digest authentication (RFC 2069 [8]) are
directly applicable.
Transport-independent: Transport-independent:
RTSP may use either an unreliable datagram protocol (UDP) [7], RTSP may use either an unreliable datagram protocol (UDP) (RFC
a reliable datagram protocol (RDP, not widely used [8]) or a 768 [9]), a reliable datagram protocol (RDP, RFC 1151, not
reliable stream protocol such as TCP [9] as it implements widely used [10]) or a reliable stream protocol such as TCP
application-level reliability. (RFC 793 [11]) as it implements application-level reliability.
Multi-server capable: Multi-server capable:
Each media stream within a presentation can reside on a Each media stream within a presentation can reside on a
different server. The client automatically establishes several different server. The client automatically establishes several
concurrent control sessions with the different media servers. concurrent control sessions with the different media servers.
Media synchronization is performed at the transport level. Media synchronization is performed at the transport level.
Control of recording devices: Control of recording devices:
The protocol can control both recording and playback devices, The protocol can control both recording and playback devices,
as well as devices that can alternate between the two modes as well as devices that can alternate between the two modes
(``VCR''). (``VCR'').
Separation of stream control and conference initiation: Separation of stream control and conference initiation:
Stream control is divorced from inviting a media server to a Stream control is divorced from inviting a media server to a
conference. The only requirement is that the conference conference. The only requirement is that the conference
initiation protocol either provides or can be used to create a initiation protocol either provides or can be used to create a
unique conference identifier. In particular, SIP [10] or H.323 unique conference identifier. In particular, SIP [12] or H.323
may be used to invite a server to a conference. [13] may be used to invite a server to a conference.
Suitable for professional applications: Suitable for professional applications:
RTSP supports frame-level accuracy through SMPTE time stamps to RTSP supports frame-level accuracy through SMPTE time stamps to
allow remote digital editing. allow remote digital editing.
Presentation description neutral: Presentation description neutral:
The protocol does not impose a particular presentation The protocol does not impose a particular presentation
description or metafile format and can convey the type of description or metafile format and can convey the type of
format to be used. However, the presentation description must format to be used. However, the presentation description must
contain at least one RTSP URI. contain at least one RTSP URI.
Proxy and firewall friendly: Proxy and firewall friendly:
The protocol should be readily handled by both application and The protocol should be readily handled by both application and
transport-layer (SOCKS [11]) firewalls. A firewall may need to transport-layer (SOCKS [14]) firewalls. A firewall may need to
understand the SETUP method to open a ``hole'' for the UDP understand the SETUP method to open a ``hole'' for the UDP
media stream. media stream.
HTTP-friendly: HTTP-friendly:
Where sensible, RTSP reuses HTTP concepts, so that the existing Where sensible, RTSP reuses HTTP concepts, so that the existing
infrastructure can be reused. This infrastructure includes PICS infrastructure can be reused. This infrastructure includes PICS
(Platform for Internet Content Selection [12,13]) for (Platform for Internet Content Selection [15,16]) for
associating labels with content. However, RTSP does not just associating labels with content. However, RTSP does not just
add methods to HTTP since the controlling continuous media add methods to HTTP since the controlling continuous media
requires server state in most cases. requires server state in most cases.
Appropriate server control: Appropriate server control:
If a client can start a stream, it must be able to stop a If a client can start a stream, it must be able to stop a
stream. Servers should not start streaming to clients in such a stream. Servers should not start streaming to clients in such a
way that clients cannot stop the stream. way that clients cannot stop the stream.
Transport negotiation: Transport negotiation:
skipping to change at line 521 skipping to change at line 521
* A server may only be capable of playback thus has no need to * A server may only be capable of playback thus has no need to
support the RECORD request. support the RECORD request.
* A server may not be capable of seeking (absolute positioning) if * A server may not be capable of seeking (absolute positioning) if
it is to support live events only. it is to support live events only.
* Some servers may not support setting stream parameters and thus * Some servers may not support setting stream parameters and thus
not support GET_PARAMETER and SET_PARAMETER. not support GET_PARAMETER and SET_PARAMETER.
A server SHOULD implement all header fields described in Section 12. A server SHOULD implement all header fields described in Section 12.
It is up to the creators of presentation descriptions not to ask the It is up to the creators of presentation descriptions not to ask the
impossible of a server. This situation is similar in HTTP/1.1, where impossible of a server. This situation is similar in HTTP/1.1 [2],
the methods described in [H19.6] are not likely to be supported across where the methods described in [H19.6] are not likely to be supported
all servers. across all servers.
RTSP can be extended in three ways, listed here in order of the RTSP can be extended in three ways, listed here in order of the
magnitude of changes supported: magnitude of changes supported:
* Existing methods can be extended with new parameters, as long as * Existing methods can be extended with new parameters, as long as
these parameters can be safely ignored by the recipient. (This is these parameters can be safely ignored by the recipient. (This is
equivalent to adding new parameters to an HTML tag.) If the client equivalent to adding new parameters to an HTML tag.) If the client
needs negative acknowledgement when a method extension is not needs negative acknowledgement when a method extension is not
supported, a tag corresponding to the extension may be added in supported, a tag corresponding to the extension may be added in
the Require: field (see Section 12.32). the Require: field (see Section 12.32).
skipping to change at line 660 skipping to change at line 660
RTSP assumes the existence of a presentation description format that RTSP assumes the existence of a presentation description format that
can express both static and temporal properties of a presentation can express both static and temporal properties of a presentation
containing several media streams. containing several media streams.
2 Notational Conventions 2 Notational Conventions
Since many of the definitions and syntax are identical to HTTP/1.1, Since many of the definitions and syntax are identical to HTTP/1.1,
this specification only points to the section where they are defined this specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer to rather than copying it. For brevity, [HX.Y] is to be taken to refer to
Section X.Y of the current HTTP/1.1 specification (RFC 2068). Section X.Y of the current HTTP/1.1 specification (RFC 2068 [2]).
All the mechanisms specified in this document are described in both All the mechanisms specified in this document are described in both
prose and an augmented Backus-Naur form (BNF) similar to that used in prose and an augmented Backus-Naur form (BNF) similar to that used in
RFC 2068 [H2.1]. It is described in detail in [14], with the [H2.1]. It is described in detail in RFC 2234 [17], with the
difference that this RTSP specification maintains the ``1#'' notation difference that this RTSP specification maintains the ``1#'' notation
for comma-separated lists. for comma-separated lists.
In this draft, we use indented and smaller-type paragraphs to provide In this draft, we use indented and smaller-type paragraphs to provide
background and motivation. This is intended to give readers who were background and motivation. This is intended to give readers who were
not involved with the formulation of the specification an not involved with the formulation of the specification an
understanding of why things are the way that they are in RTSP. understanding of why things are the way that they are in RTSP.
3 Protocol Parameters 3 Protocol Parameters
skipping to change at line 689 skipping to change at line 689
3.2 RTSP URL 3.2 RTSP URL
The ``rtsp'', ``rtspu'' and ``rtsps'' schemes are used to refer to The ``rtsp'', ``rtspu'' and ``rtsps'' schemes are used to refer to
network resources via the RTSP protocol. This section defines the network resources via the RTSP protocol. This section defines the
scheme-specific syntax and semantics for RTSP URLs. scheme-specific syntax and semantics for RTSP URLs.
rtsp_URL = ( "rtsp:" | "rtspu:" | "rtsps:" ) rtsp_URL = ( "rtsp:" | "rtspu:" | "rtsps:" )
"//" host [ ":" port ] [ abs_path ] "//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP address host = <A legal Internet host domain name of IP address
(in dotted decimal form), as defined by Section 2.1 (in dotted decimal form), as defined by Section 2.1
of RFC 1123> of RFC 1123 \cite{rfc1123}>
port = *DIGIT port = *DIGIT
abs_path is defined in [H3.2.1]. abs_path is defined in [H3.2.1].
Note that fragment and query identifiers do not have a well-defined Note that fragment and query identifiers do not have a well-defined
meaning at this time, with the interpretation left to the RTSP meaning at this time, with the interpretation left to the RTSP
server. server.
The scheme rtsp requires that commands are issued via a reliable The scheme rtsp requires that commands are issued via a reliable
protocol (within the Internet, TCP), while the scheme rtspu identifies protocol (within the Internet, TCP), while the scheme rtspu identifies
an unreliable protocol (within the Internet, UDP). The scheme rtsps an unreliable protocol (within the Internet, UDP). The scheme rtsps
indicates that a TCP connection secured by TLS (RFC XXXX) must be indicates that a TCP connection secured by TLS (RFC XXXX) [7] must be
used. used.
If the port is empty or not given, port 554 is assumed. The semantics If the port is empty or not given, port 554 is assumed. The semantics
are that the identified resource can be controlled by RTSP at the are that the identified resource can be controlled by RTSP at the
server listening for TCP (scheme ``rtsp'') connections or UDP (scheme server listening for TCP (scheme ``rtsp'') connections or UDP (scheme
``rtspu'') packets on that port of host, and the Request-URI for the ``rtspu'') packets on that port of host, and the Request-URI for the
resource is rtsp_URL. resource is rtsp_URL.
The use of IP addresses in URLs SHOULD be avoided whenever possible The use of IP addresses in URLs SHOULD be avoided whenever possible
(see RFC 1924 [15]). (see RFC 1924 [19]).
A presentation or a stream is identified by a textual media A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions [H3.2] of identifier, using the character set and escape conventions [H3.2] of
URLs [16]. URLs may refer to a stream or an aggregate of streams, URLs (RFC 1738 [20]). URLs may refer to a stream or an aggregate of
i.e., a presentation. Accordingly, requests described in Section 10 streams, i.e., a presentation. Accordingly, requests described in
can apply to either the whole presentation or an individual stream Section 10 can apply to either the whole presentation or an individual
within the presentation. Note that some request methods can only be stream within the presentation. Note that some request methods can
applied to streams, not presentations and vice versa. only be applied to streams, not presentations and vice versa.
For example, the RTSP URL: For example, the RTSP URL:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
identifies the audio stream within the presentation ``twister'', which identifies the audio stream within the presentation ``twister'', which
can be controlled via RTSP requests issued over a TCP connection to can be controlled via RTSP requests issued over a TCP connection to
port 554 of host media.example.com. port 554 of host media.example.com.
Also, the RTSP URL: Also, the RTSP URL:
rtsp://media.example.com:554/twister rtsp://media.example.com:554/twister
skipping to change at line 759 skipping to change at line 759
Conference identifiers are opaque to RTSP and are encoded using Conference identifiers are opaque to RTSP and are encoded using
standard URI encoding methods (i.e., LWS is escaped with %). They can standard URI encoding methods (i.e., LWS is escaped with %). They can
contain any octet value. The conference identifier MUST be globally contain any octet value. The conference identifier MUST be globally
unique. For H.323, the conferenceID value is to be used. unique. For H.323, the conferenceID value is to be used.
conference-id = 1*xchar conference-id = 1*xchar
Conference identifiers are used to allow RTSP sessions to obtain Conference identifiers are used to allow RTSP sessions to obtain
parameters from multimedia conferences the media server is parameters from multimedia conferences the media server is
participating in. These conferences are created by protocols participating in. These conferences are created by protocols
outside the scope of this specification, e.g., H.323 [17] or SIP outside the scope of this specification, e.g., H.323 [13] or SIP
[10]. Instead of the RTSP client explicitly providing transport [12]. Instead of the RTSP client explicitly providing transport
information, for example, it asks the media server to use the information, for example, it asks the media server to use the
values in the conference description instead. values in the conference description instead.
3.4 Session Identifiers 3.4 Session Identifiers
Session identifiers are opaque strings of arbitrary length. Linear Session identifiers are opaque strings of arbitrary length. Linear
white space must be URL-escaped. A session identifier MUST be chosen white space must be URL-escaped. A session identifier MUST be chosen
randomly and MUST be at least eight octets long to make guessing it randomly and MUST be at least eight octets long to make guessing it
more difficult. (See Section 16.) more difficult. (See Section 16.)
skipping to change at line 893 skipping to change at line 892
* A reference to a further description, if available, for example * A reference to a further description, if available, for example
(in order of preference) an RFC, a published paper, a patent (in order of preference) an RFC, a published paper, a patent
filing, a technical report, documented source code or a computer filing, a technical report, documented source code or a computer
manual; manual;
* For proprietary options, contact information (postal and email * For proprietary options, contact information (postal and email
address); address);
4 RTSP Message 4 RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set RTSP is a text-based protocol and uses the ISO 10646 character set
in UTF-8 encoding (RFC 2044). Lines are terminated by CRLF, but in UTF-8 encoding (RFC XXXX [21]). Lines are terminated by CRLF, but
receivers should be prepared to also interpret CR and LF by themselves receivers should be prepared to also interpret CR and LF by themselves
as line terminators. as line terminators.
Text-based protocols make it easier to add optional parameters in a Text-based protocols make it easier to add optional parameters in a
self-describing manner. Since the number of parameters and the self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if done carefully, also allow easy concern. Text-based protocols, if done carefully, also allow easy
implementation of research prototypes in scripting languages such implementation of research prototypes in scripting languages such
as Tcl, Visual Basic and Perl. as Tcl, Visual Basic and Perl.
The 10646 character set avoids tricky character set switching, but The 10646 character set avoids tricky character set switching, but
is invisible to the application as long as US-ASCII is being used. is invisible to the application as long as US-ASCII is being used.
This is also the encoding used for RTCP. ISO 8859-1 translates This is also the encoding used for RTCP. ISO 8859-1 translates
directly into Unicode with a high-order octet of zero. ISO 8859-1 directly into Unicode with a high-order octet of zero. ISO 8859-1
characters with the most-significant bit set are represented as characters with the most-significant bit set are represented as
1100001x 10xxxxxx. 1100001x 10xxxxxx. (See RFC XXXX [21])
RTSP messages can be carried over any lower-layer transport protocol RTSP messages can be carried over any lower-layer transport protocol
that is 8-bit clean. that is 8-bit clean.
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent, parameters to further describe the method. Methods are idempotent,
unless otherwise noted. Methods are also designed to require little or unless otherwise noted. Methods are also designed to require little or
no state maintenance at the media server. no state maintenance at the media server.
4.1 Message Types 4.1 Message Types
skipping to change at line 1022 skipping to change at line 1020
request-header = Accept ; Section 12.1 request-header = Accept ; Section 12.1
| Accept-Encoding ; Section 12.2 | Accept-Encoding ; Section 12.2
| Accept-Language ; Section 12.3 | Accept-Language ; Section 12.3
| Authorization ; Section 12.5 | Authorization ; Section 12.5
| From ; Section 12.20 | From ; Section 12.20
| If-Modified-Since ; Section 12.23 | If-Modified-Since ; Section 12.23
| Range ; Section 12.29 | Range ; Section 12.29
| Referer ; Section 12.30 | Referer ; Section 12.30
| User-Agent ; Section 12.41 | User-Agent ; Section 12.41
Note that in contrast to HTTP/1.1, RTSP requests always contain the Note that in contrast to HTTP/1.1 [2], RTSP requests always contain
absolute URL (that is, including the scheme, host and port) rather the absolute URL (that is, including the scheme, host and port) rather
than just the absolute path. than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URL, but HTTP/1.1 requires servers to understand the absolute URL, but
clients are supposed to use the Host request header. This is purely clients are supposed to use the Host request header. This is purely
needed for backward-compatibility with HTTP/1.0 servers, a needed for backward-compatibility with HTTP/1.0 servers, a
consideration that does not apply to RTSP. consideration that does not apply to RTSP.
The asterisk "*" in the Request-URI means that the request does not The asterisk "*" in the Request-URI means that the request does not
apply to a particular resource, but to the server itself, and is only apply to a particular resource, but to the server itself, and is only
allowed when the method used does not necessarily apply to a resource. allowed when the method used does not necessarily apply to a resource.
skipping to change at line 1088 skipping to change at line 1086
* 1xx: Informational - Request received, continuing process * 1xx: Informational - Request received, continuing process
* 2xx: Success - The action was successfully received, understood, * 2xx: Success - The action was successfully received, understood,
and accepted and accepted
* 3xx: Redirection - Further action must be taken in order to * 3xx: Redirection - Further action must be taken in order to
complete the request complete the request
* 4xx: Client Error - The request contains bad syntax or cannot be * 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled fulfilled
* 5xx: Server Error - The server failed to fulfill an apparently * 5xx: Server Error - The server failed to fulfill an apparently
valid request valid request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
RTSP/1.0, and an example set of corresponding Reason-Phrase's, are RTSP/1.0, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only recommended - presented below. The reason phrases listed here are only recommended -
they may be replaced by local equivalents without affecting the they may be replaced by local equivalents without affecting the
protocol. Note that RTSP adopts most HTTP/1.1 status codes and adds protocol. Note that RTSP adopts most HTTP/1.1 [2] status codes and
RTSP-specific status codes starting at x50 to avoid conflicts with adds RTSP-specific status codes starting at x50 to avoid conflicts
newly defined HTTP status codes. with newly defined HTTP status codes.
Status-Code = "100" ; Continue Status-Code = "100" ; Continue
| "200" ; OK | "200" ; OK
| "201" ; Created | "201" ; Created
| "250" ; Low on Storage Space | "250" ; Low on Storage Space
| "300" ; Multiple Choices | "300" ; Multiple Choices
| "301" ; Moved Permanently | "301" ; Moved Permanently
| "302" ; Moved Temporarily | "302" ; Moved Temporarily
| "303" ; See Other | "303" ; See Other
| "304" ; Not Modified | "304" ; Not Modified
skipping to change at line 1302 skipping to change at line 1299
A client that supports persistent connections or connectionless mode A client that supports persistent connections or connectionless mode
MAY ``pipeline'' its requests (i.e., send multiple requests without MAY ``pipeline'' its requests (i.e., send multiple requests without
waiting for each response). A server MUST send its responses to those waiting for each response). A server MUST send its responses to those
requests in the same order that the requests were received. requests in the same order that the requests were received.
9.2 Reliability and Acknowledgements 9.2 Reliability and Acknowledgements
Requests are acknowledged by the receiver unless they are sent to a Requests are acknowledged by the receiver unless they are sent to a
multicast group. If there is no acknowledgement, the sender may resend multicast group. If there is no acknowledgement, the sender may resend
the same message after a timeout of one round-trip time (RTT). The the same message after a timeout of one round-trip time (RTT). The
round-trip time is estimated as in TCP (RFC 1123), with an initial round-trip time is estimated as in TCP (RFC 1123) [18], with an
round-trip value of 500 ms. An implementation MAY cache the last RTT initial round-trip value of 500 ms. An implementation MAY cache the
measurement as the initial value for future connections. If a reliable last RTT measurement as the initial value for future connections.
transport protocol is used to carry RTSP, the timeout value MAY be set
to an arbitrarily large value.
This can greatly increase responsiveness for proxies operating in If a reliable transport protocol is used to carry RTSP, requests
local-area networks with small RTTs. The mechanism is defined such SHOULD NOT be retransmitted; the RTSP application SHOULD instead rely
that the client implementation does not have to be aware of whether on the underlying transport to provide reliability.
a reliable or unreliable transport protocol is being used. It is
probably a bad idea to have two reliability mechanisms on top of If both the underlying reliable transport such as TCP and the RTSP
each other, although the RTSP RTT estimate is likely to be larger application retransmit requests, it is possible that each packet
than the TCP estimate. loss results in two retransmissions. The receiver cannot typically
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.
If RTSP is used over a small-RTT LAN, standard procedures for
optimizing inital TCP round trip estimates, such as those used in
T/TCP (RFC 1644) [22], can be beneficial.
The Timestamp header (Section 12.38) is used to avoid the The Timestamp header (Section 12.38) is used to avoid the
retransmission ambiguity problem [18, p. 301] and obviates the need retransmission ambiguity problem [23, p. 301] and obviates the need
for Karn's algorithm. for Karn's algorithm.
Each request carries a sequence number in the CSeq header Each request carries a sequence number in the CSeq header
(Section 12.17), which is incremented by one for each distinct request (Section 12.17), which is incremented by one for each distinct request
transmitted. If a request is repeated because of lack of transmitted. If a request is repeated because of lack of
acknowledgement, the request MUST carry the original sequence number acknowledgement, the request MUST carry the original sequence number
(i.e. sequence number is not incremented). (i.e. sequence number is not incremented).
Systems implementing RTSP MUST support carrying RTSP over TCP and MAY Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
support UDP. The default port for the RTSP server is 554 for both UDP support UDP. The default port for the RTSP server is 554 for both UDP
skipping to change at line 1972 skipping to change at line 1975
parameter in the Transport field. parameter in the Transport field.
11.3.14 551 Option not supported 11.3.14 551 Option not supported
An option given in the Require or the Proxy-Require fields was not An option given in the Require or the Proxy-Require fields was not
supported. The Unsupported header should be returned stating the supported. The Unsupported header should be returned stating the
option for which there is no support. option for which there is no support.
12 Header Field Definitions 12 Header Field Definitions
HTTP/1.1 or other, non-standard header fields not listed here HTTP/1.1 [2] or other, non-standard header fields not listed here
currently have no well-defined meaning and SHOULD be ignored by the currently have no well-defined meaning and SHOULD be ignored by the
recipient. recipient.
Table 3 summarizes the header fields used by RTSP. Type ``g'' Table 3 summarizes the header fields used by RTSP. Type ``g''
designates general request headers to be found in both requests and designates general request headers to be found in both requests and
responses, type ``R'' designates request headers, type ``r'' responses, type ``R'' designates request headers, type ``r''
designates response headers, and type ``e'' designates entity header designates response headers, and type ``e'' designates entity header
fields. Fields marked with ``req.'' in the column labeled ``support'' fields. Fields marked with ``req.'' in the column labeled ``support''
MUST be implemented by the recipient for a particular method, while MUST be implemented by the recipient for a particular method, while
fields marked ``opt.'' are optional. Note that not all fields marked fields marked ``opt.'' are optional. Note that not all fields marked
skipping to change at line 2399 skipping to change at line 2402
is not understood, the recipient should return ``501 Not is not understood, the recipient should return ``501 Not
Implemented''. Implemented''.
Range = "Range" ":" 1#ranges-specifier Range = "Range" ":" 1#ranges-specifier
[ ";" "time" "=" utc-time ] [ ";" "time" "=" utc-time ]
ranges-specifier = npt-range | utc-range | smpte-range ranges-specifier = npt-range | utc-range | smpte-range
Example: Example:
Range: clock=19960213T143205Z-;time=19970123T143720Z Range: clock=19960213T143205Z-;time=19970123T143720Z
The notation is similar to that used for the HTTP/1.1 byterange The notation is similar to that used for the HTTP/1.1 [2]
header. It allows clients to select an excerpt from the media byte-range header. It allows clients to select an excerpt from the
object, and to play from a given point to the end as well as from media object, and to play from a given point to the end as well as
the current location to a given point. The start of playback can be from the current location to a given point. The start of playback
scheduled for any time in the future, although a server may refuse can be scheduled for any time in the future, although a server may
to keep server resources for extended idle periods. refuse to keep server resources for extended idle periods.
12.30 Referer 12.30 Referer
See [H14.37]. The URL refers to that of the presentation See [H14.37]. The URL refers to that of the presentation
description, typically retrieved via HTTP. description, typically retrieved via HTTP.
12.31 Retry-After 12.31 Retry-After
See [H14.38]. See [H14.38].
skipping to change at line 2730 skipping to change at line 2733
This parameter provides the unicast RTP/RTCP port pair on the This parameter provides the unicast RTP/RTCP port pair on the
client where media data and control information is to be sent. client where media data and control information is to be sent.
It is specified as a range, e.g., port=3456-3457. It is specified as a range, e.g., port=3456-3457.
server_port: server_port:
This parameter provides the unicast RTP/RTCP port pair on the This parameter provides the unicast RTP/RTCP port pair on the
server where media data and control information is to be sent. server where media data and control information is to be sent.
It is specified as a range, e.g., port=3456-3457. It is specified as a range, e.g., port=3456-3457.
ssrc: ssrc:
The ssrc parameter indicates the RTP SSRC [19, Sec. 3] value The ssrc parameter indicates the RTP SSRC [24, Sec. 3] value
that should be (request) or will be (response) used by the that should be (request) or will be (response) used by the
media server. This parameter is only valid for unicast media server. This parameter is only valid for unicast
transmission. It identifies the synchronization source to be transmission. It identifies the synchronization source to be
associated with the media stream. associated with the media stream.
Transport = "Transport" ":" Transport = "Transport" ":"
1\#transport-spec 1\#transport-spec
transport-spec = transport-protocol/profile[/lower-transport] transport-spec = transport-protocol/profile[/lower-transport]
*parameter *parameter
transport-protocol = "RTP" transport-protocol = "RTP"
skipping to change at line 3273 skipping to change at line 3276
CSeq: 93 CSeq: 93
Session: 508876 Session: 508876
Range: clock=19961110T1925-19961110T2015 Range: clock=19961110T1925-19961110T2015
M->C: RTSP/1.0 200 OK M->C: RTSP/1.0 200 OK
CSeq: 93 CSeq: 93
15 Syntax 15 Syntax
The RTSP syntax is described in an augmented Backus-Naur form (BNF) The RTSP syntax is described in an augmented Backus-Naur form (BNF)
as used in RFC 2068 (HTTP/1.1). as used in RFC 2068 [2].
15.1 Base Syntax 15.1 Base Syntax
OCTET = <any 8-bit sequence of data> OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)> CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z"> LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9"> DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character CTL = <any US-ASCII control character
skipping to change at line 3387 skipping to change at line 3390
Location Headers and Spoofing: Location Headers and Spoofing:
If a single server supports multiple organizations that do not If a single server supports multiple organizations that do not
trust one another, then it must check the values of Location trust one another, then it must check the values of Location
and Content-Location headers in responses that are generated and Content-Location headers in responses that are generated
under control of said organizations to make sure that they do under control of said organizations to make sure that they do
not attempt to invalidate resources over which they have no not attempt to invalidate resources over which they have no
authority. ([H15.9]) authority. ([H15.9])
In addition to the recommendations in the current HTTP specification In addition to the recommendations in the current HTTP specification
(RFC 2068, as of this writing), future HTTP specifications may provide (RFC 2068 [2], as of this writing), future HTTP specifications may
additional guidance on security issues. provide additional guidance on security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Concentrated Denial-Of-Service: Concentrated denial-of-service attack:
The protocol offers the opportunity for a remote-controlled The protocol offers the opportunity for a remote-controlled
denial-of-service attack. The attacker may initiate traffic denial-of-service attack. The attacker may initiate traffic
flows to one or more IP addresses by specifying them as the flows to one or more IP addresses by specifying them as the
destination in SETUP requests. While the attacker's IP address destination in SETUP requests. While the attacker's IP address
may be known in this case, this is not always useful in may be known in this case, this is not always useful in
prevention of more attacks or ascertaining the attackers prevention of more attacks or ascertaining the attackers
identity. Thus, an RTSP server SHOULD only allow identity. Thus, an RTSP server SHOULD only allow
client-specified destinations for RTSP-initiated traffic flows client-specified destinations for RTSP-initiated traffic flows
if the server has verified the client's identity, either if the server has verified the client's identity, either
against a database of known users using RTSP authentication against a database of known users using RTSP authentication
mechanisms (preferrably digest authentication or stronger), or mechanisms (preferrably digest authentication or stronger), or
other secure means. other secure means.
Session Hijacking: Session hijacking:
Since there is no relation between a transport layer connection Since there is no relation between a transport layer connection
and an RTSP session, it is possible for a malicious client to and an RTSP session, it is possible for a malicious client to
issue requests with random session identifiers which would issue requests with random session identifiers which would
affect unsuspecting clients. The server SHOULD use a large, affect unsuspecting clients. The server SHOULD use a large,
random and non-sequential session identifier to minimize the random and non-sequential session identifier to minimize the
possibility of this kind of attack. possibility of this kind of attack.
Authentication: Authentication:
Servers SHOULD implement both basic and digest [6] Servers SHOULD implement both basic and digest [8]
authentication. In environments requiring tighter security for authentication. In environments requiring tighter security for
the control messages, transport layer mechanisms such as TLS the control messages, transport layer mechanisms such as TLS
(RFC XXXX) SHOULD be used. (RFC XXXX [7]) SHOULD be used.
Stream issues: Stream issues:
RTSP only provides for stream control. Stream delivery issues RTSP only provides for stream control. Stream delivery issues
are not covered in this section, nor in the rest of this draft. are not covered in this section, nor in the rest of this draft.
RTSP implementations will most likely rely on other protocols RTSP implementations will most likely rely on other protocols
such as RTP, IP Multicast, RSVP, and IGMP, and should address such as RTP, IP multicast, RSVP and IGMP, and should address
considerations brought up in these specifications (even when security considerations brought up in those and other
non-standard equivalents are used in place of said protocols). applicable specifications.
Persistently suspicious behavior: Persistently suspicious behavior:
RTSP servers SHOULD return error code 403 (Forbidden) upon RTSP servers SHOULD return error code 403 (Forbidden) upon
receiving a single instance of behavior which is deemed a receiving a single instance of behavior which is deemed a
security risk. RTSP servers SHOULD also be aware of attempts to security risk. RTSP servers SHOULD also be aware of attempts to
probe the server for weaknesses and entry points and MAY probe the server for weaknesses and entry points and MAY
arbitrarily disconnect and ignore further requests clients arbitrarily disconnect and ignore further requests clients
which are deemed to be in violation of local security policy. which are deemed to be in violation of local security policy.
Appendix A: RTSP Protocol State Machines Appendix A: RTSP Protocol State Machines
skipping to change at line 3575 skipping to change at line 3578
SETUP Playing SETUP Playing
Recording RECORD Recording Recording RECORD Recording
PAUSE Ready PAUSE Ready
TEARDOWN Init TEARDOWN Init
SETUP Recording SETUP Recording
Appendix B: Interaction with RTP Appendix B: Interaction with RTP
RTSP allows media clients to control selected, non-contiguous RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP sections of media presentations, rendering those streams with an RTP
media layer[19]. The media layer rendering the RTP stream should not media layer[24]. The media layer rendering the RTP stream should not
be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP
timestamps MUST be continuous and monotonic across jumps of NPT. timestamps MUST be continuous and monotonic across jumps of NPT.
As an example, assume a clock frequency of 8000 Hz, a packetization As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of interval of 100 ms and an initial sequence number and timestamp of
zero. First we play NPT 10 through 15, then skip ahead and play NPT 18 zero. First we play NPT 10 through 15, then skip ahead and play NPT 18
through 20. The first segment is presented as RTP packets with through 20. The first segment is presented as RTP packets with
sequence numbers 0 through 49 and timestamp 0 through 39,200. The sequence numbers 0 through 49 and timestamp 0 through 39,200. The
second segment consists of RTP packets with sequence number 50 through second segment consists of RTP packets with sequence number 50 through
69, with timestamps 40,000 through 55,200. 69, with timestamps 40,000 through 55,200.
skipping to change at line 3619 skipping to change at line 3622
packets with the normal timestamp spacing of 3,000 per frame, but NPT packets with the normal timestamp spacing of 3,000 per frame, but NPT
would increase by 1/15 second for each video frame. would increase by 1/15 second for each video frame.
The client can maintain a correct display of NPT by noting the RTP The client can maintain a correct display of NPT by noting the RTP
timestamp value of the first packet arriving after repositioning. The timestamp value of the first packet arriving after repositioning. The
sequence parameter of the RTP-Info (Section 12.33) header provides the sequence parameter of the RTP-Info (Section 12.33) header provides the
first sequence number of the next segment. first sequence number of the next segment.
Appendix C: Use of SDP for RTSP Session Descriptions Appendix C: Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, RFC XXXX) may be used to The Session Description Protocol (SDP, RFC XXXX [6]) may be used to
describe streams or presentations in RTSP. Such usage is limited to describe streams or presentations in RTSP. Such usage is limited to
specifying means of access and encoding(s) for: specifying means of access and encoding(s) for:
aggregate control: aggregate control:
A presentation composed of streams from one or more servers A presentation composed of streams from one or more servers
that are not available for aggregate control. Such a that are not available for aggregate control. Such a
description is typically retrieved by HTTP or other non-RTSP description is typically retrieved by HTTP or other non-RTSP
means. However, they may be received with ANNOUNCE methods. means. However, they may be received with ANNOUNCE methods.
non-aggregate control: non-aggregate control:
skipping to change at line 3647 skipping to change at line 3650
describes how a client should interpret SDP content returned in reply describes how a client should interpret SDP content returned in reply
to a DESCRIBE request. SDP provides no mechanism by which a client can to a DESCRIBE request. SDP provides no mechanism by which a client can
distinguish, without human guidance, between several media streams to distinguish, without human guidance, between several media streams to
be rendered simultaneously and a set of alternatives (e.g., two audio be rendered simultaneously and a set of alternatives (e.g., two audio
streams spoken in different languages). streams spoken in different languages).
C.1 Definitions C.1 Definitions
The terms ``session-level'', ``media-level'' and other key/attribute The terms ``session-level'', ``media-level'' and other key/attribute
names and values used in this appendix are to be used as defined in names and values used in this appendix are to be used as defined in
RFC XXXX (SDP): SDP (RFC XXXX [6]):
C.1.1 Control URL C.1.1 Control URL
The ``a=control:'' attribute is used to convey the control URL. This The ``a=control:'' attribute is used to convey the control URL. This
attribute is used both for the session and media descriptions. If used attribute is used both for the session and media descriptions. If used
for individual media, it indicates the URL to be used for controlling for individual media, it indicates the URL to be used for controlling
that particular media stream. If found at the session level, the that particular media stream. If found at the session level, the
attribute indicates the URL for aggregate control. attribute indicates the URL for aggregate control.
Example: Example:
a=control:rtsp://example.com/foo a=control:rtsp://example.com/foo
This attribute may contain either relative and absolute URLs, This attribute may contain either relative and absolute URLs,
following the rules and conventions set out in RFC 1808 ([20]). following the rules and conventions set out in RFC 1808 [25].
Implementations should look for a base URL in the following order: Implementations should look for a base URL in the following order:
1. The RTSP Content-Base field 1. The RTSP Content-Base field
2. The RTSP Content-Location field 2. The RTSP Content-Location field
3. The RTSP request URL 3. The RTSP request URL
If this attribute contains only an asterisk (*), then the URL is If this attribute contains only an asterisk (*), then the URL is
treated as if it were an empty embedded URL, and thus inherits the treated as if it were an empty embedded URL, and thus inherits the
entire base URL. entire base URL.
skipping to change at line 3687 skipping to change at line 3690
a recommendation from the server to the client; the client still has a recommendation from the server to the client; the client still has
to include it in its SETUP request and may ignore this recommendation. to include it in its SETUP request and may ignore this recommendation.
If the server has no preference, it SHOULD set the port number value If the server has no preference, it SHOULD set the port number value
to zero. to zero.
Example: Example:
m=audio 0 RTP/AVP 31 m=audio 0 RTP/AVP 31
C.1.3 Payload type(s) C.1.3 Payload type(s)
The payload type(s) are specified in the ``m='' field. In case the The payload type(s) are specified in the ``m='' field. In case the
payload type is a static payload type from RFC 1890([1]), no other payload type is a static payload type from RFC 1890 [1], no other
information is required. In case it is a dynamic payload type, the information is required. In case it is a dynamic payload type, the
media attribute ``rtpmap'' is used to specify what the media is. The media attribute ``rtpmap'' is used to specify what the media is. The
``encoding name'' within the ``rtpmap'' attribute may be one of those ``encoding name'' within the ``rtpmap'' attribute may be one of those
specified in RFC 1890 (Sections 5 and 6), or an experimental encoding specified in RFC 1890 (Sections 5 and 6), or an experimental encoding
with a ``X-'' prefix as specified in RFC XXXX (SDP). Codec-specific with a ``X-'' prefix as specified in SDP (RFC XXXX [6]).
parameters are not specified in this field, but rather in the ``fmtp'' Codec-specific parameters are not specified in this field, but rather
attribute described below. Implementors seeking to register new in the ``fmtp'' attribute described below. Implementors seeking to
encodings should follow the procedure in RFC 1890. If the media type register new encodings should follow the procedure in RFC 1890 [1]. If
is not suited to the RTP AV profile, then it is recommended that a new the media type is not suited to the RTP AV profile, then it is
profile be created and the appropriate profile name be used in lieu of recommended that a new profile be created and the appropriate profile
``RTP/AVP'' in the ``m='' field. name be used in lieu of ``RTP/AVP'' in the ``m='' field.
C.1.4 Format-specific parameters C.1.4 Format-specific parameters
Format-specific parameters are conveyed using the ``fmtp'' media Format-specific parameters are conveyed using the ``fmtp'' media
attribute. The syntax of the ``fmtp'' attribute is specific to the attribute. The syntax of the ``fmtp'' attribute is specific to the
encoding(s) that the attribute refers to. Note that the packetization encoding(s) that the attribute refers to. Note that the packetization
interval is conveyed using the ``ptime'' attribute. interval is conveyed using the ``ptime'' attribute.
C.1.5 Range of presentation C.1.5 Range of presentation
skipping to change at line 3956 skipping to change at line 3959
D.2.2 Authentication-enabled D.2.2 Authentication-enabled
In order to correctly handle client authentication, the server MUST In order to correctly handle client authentication, the server MUST
additionally be able to do the following: additionally be able to do the following:
* Generate the 401 status code when authentication is required for * Generate the 401 status code when authentication is required for
the resource. the resource.
* Parse and include the WWW-Authenticate header * Parse and include the WWW-Authenticate header
* Implement Basic Authentication and Digest Authentication * Implement Basic Authentication and Digest Authentication
Appendix E: Changes Appendix E: Author Addresses
Since draft 06 (November 21, 1997 version) of RTSP, the following
changes were made:
* Added "Persistently suspicious behavior" to Security
Considerations (Section 16).
* Fixed examples in the explanation of NPT (Section 3.6).
* Session identifiers MUST be chosen at random and must be at least
8 octets long (Section 3.4). (Formerly, this was only SHOULD).
* Made XXXX reference to SDP more clearly belong to SDP in Appendix
C (still needs to be fixed when SDP gets an RFC number).
Since draft 05 (October 28, 1997 version) of RTSP, the following
changes were made:
* Added reference to Timestamp: header.
* Added some RTP-Info headers to PLAY responses in example code.
* Added atomicity wording to SET_PARAMETER.
* Added support for smpte-25.
* Added Allow header to header table.
* Changed smpte and npt to allow 1*2DIGIT.
* Changed RTP-Info from providing the last sequence number of the
previous segment to first sequence number of the next segment.
* Changed SDP a=length to a=range.
* Described ``append'' Transport parameter further.
* Fixed bugs in CSeq wording (was per packet, now per request).
* Fleshed out security section reference to HTTP by explaining why
each of the HTTP recommendations are applicable to RTSP.
* Allow server initiated OPTIONS exchange
* Fixed wording on the Range header support for minimal
implementations.
* Updated section and example to interleave RTCP packets on the TCP
connection well.
Since draft 04 (September 17, 1997 version) of RTSP, the following
changes were made:
* Further explanation of container files and how to deal with
``single-stream container files''.
* IANA procedure for registering option tags.
* New response codes (``461 Unsupported Transport'', ``462
Destination Unreachable'', ``551 Option Not Supported'').
* Practical minimum implementations established in Appendix D.
* Removed quasi-specification of ``text/rtsp-parameters'' with the
intent to define this separately.
* Closed out open issues
* Inserted ommisions in ``Since draft03...'' below (``etag''
change).
* Addition of ``etag'' mechanism in SDP, and corresponding If-Match
field.
Since draft 03 (July 30, 1997 version) of RTSP, the following changes
were made:
* PEP was removed, Require header returns. Motivation: We explored
using the W3C's PEP proposal for this functionality. However,
Require, Proxy-Require, and Unsupported allow the addition of
extensions with far less complexity. The Proxy-Require field
roughly corresponds to the C-PEP field in the PEP draft. The
Require field roughly corresponds to the PEP field in the PEP
draft. The Unsupported field roughly corresponds to the PEP-Info
and C-PEP-Info in the PEP draft.
* Usage of SDP within RTSP is specified as an appendix.
* Minimal RTSP implementation specified as an appendix.
* The RTSP control sequence number was moved from the request and
response lines into its own CSeq header.
* Appendix detailing interaction with RTP added.
* Several changes to Transport and RTP-Info fields. RTP-Info was
formerly Transport-Info.
* Addition of etag mechanism in SDP, and corresponding If-Match
field.
Between draft 02 (March, 1997) and draft 03 (July, 1997), the
following changes were made:
* Definition of RTP behavior.
* Definition of behavior for container files.
* Remove server-to-client DESCRIBE request.
* Allowing the Transport header to direct media streams to unicast
and multicast addresses, with an appropriate warning about
denial-of-service attacks.
* Add mode parameter to Transport header to allow RECORD or PLAY.
* The Embedded binary data section was modified to clearly indicate
the stream the data corresponds to, and a reference to the
Transport header was added.
* The Transport header format has been changed to use a more general
means to specify data channel and application-level protocol. It
also conveys the port to be used at the server for RTCP messages,
and the start sequence number that will be used in the RTP
packets.
* The use of the Session: header has been enhanced. Requests for
multiple URLs may be sent in a single session.
* There is a distinction between aggregate (presentation) URLs and
stream URLs. Error codes have been added to reflect the fact that
some methods may be allowed only on a particular type of URL.
* Example showing the use of aggregate/presentation control using a
single RTSP session has been added.
* Support for the PEP (Protocol Extension Protocol) headers has been
added.
* Server-Client DESCRIBE messages have been renamed to ANNOUNCE for
better clarity and differentiation.
Note that this list does not reflect minor changes in wording or
correction of typographical errors.
Appendix F: Author Addresses
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
electronic mail: schulzrinne@cs.columbia.edu electronic mail: schulzrinne@cs.columbia.edu
Anup Rao Anup Rao
skipping to change at line 4087 skipping to change at line 3983
USA USA
electronic mail: anup@netscape.com electronic mail: anup@netscape.com
Robert Lanphier Robert Lanphier
RealNetworks RealNetworks
1111 Third Avenue Suite 2900 1111 Third Avenue Suite 2900
Seattle, WA 98101 Seattle, WA 98101
USA USA
electronic mail: robla@prognet.com electronic mail: robla@prognet.com
Appendix G: Acknowledgements Appendix F: Acknowledgements
This draft is based on the functionality of the original RTSP draft This draft is based on the functionality of the original RTSP draft
submitted in October 96. It also borrows format and descriptions from submitted in October 96. It also borrows format and descriptions from
HTTP/1.1. HTTP/1.1.
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already participating in the MMUSIC-WG. In addition to those already
mentioned, the following individuals have contributed to this mentioned, the following individuals have contributed to this
specification: specification:
skipping to change at line 4114 skipping to change at line 4010
Papadopouli, Sujal Patel, Alagu Periyannan, Igor Plotnikov, Pinaki Papadopouli, Sujal Patel, Alagu Periyannan, Igor Plotnikov, Pinaki
Shah, David Singer, Jeff Smith, Alexander Sokolsky, Dale Stammen, and Shah, David Singer, Jeff Smith, Alexander Sokolsky, Dale Stammen, and
John Francis Stracke. John Francis Stracke.
References References
1 H. Schulzrinne, ``RTP profile for audio and video conferences 1 H. Schulzrinne, ``RTP profile for audio and video conferences
with minimal control,'' RFC 1890, Internet Engineering Task with minimal control,'' RFC 1890, Internet Engineering Task
Force, Jan. 1996. Force, Jan. 1996.
2 F. Yergeau, G. Nicol, G. Adams, and M. Duerst, 2 R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T.
Berners-Lee, ``Hypertext transfer protocol - HTTP/1.1,'' RFC
2068, Internet Engineering Task Force, Jan. 1997.
3 F. Yergeau, G. Nicol, G. Adams, and M. Duerst,
``Internationalization of the hypertext markup language,'' RFC ``Internationalization of the hypertext markup language,'' RFC
2070, Internet Engineering Task Force, Jan. 1997. 2070, Internet Engineering Task Force, Jan. 1997.
3 S. Bradner, ``Key words for use in RFCs to indicate requirement 4 S. Bradner, ``Key words for use in RFCs to indicate requirement
levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997. levels,'' RFC 2119, Internet Engineering Task Force, Mar. 1997.
4 R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T.
Berners-Lee, ``Hypertext transfer protocol - HTTP/1.1,'' RFC
2068, Internet Engineering Task Force, Jan. 1997.
5 ISO/IEC, ``Information technology - generic coding of moving 5 ISO/IEC, ``Information technology - generic coding of moving
pictures and associated audio informaiton - part 6: extension pictures and associated audio informaiton - part 6: extension
for digital storage media and control,'' Draft International for digital storage media and control,'' Draft International
Standard ISO 13818-6, International Organization for Standard ISO 13818-6, International Organization for
Standardization ISO/IEC JTC1/SC29/WG11, Geneva, Switzerland, Standardization ISO/IEC JTC1/SC29/WG11, Geneva, Switzerland,
Nov. 1995. Nov. 1995.
6 J. Franks, P. Hallam-Baker, and J. Hostetler, ``An extension to 6 M. Handley and V. Jacobson, ``SDP: Session description
protocol,'' Request for Comments XXXX, Internet Engineering
Task Force, Feb. 1998.
7 A. Freier, P. Karlton, and P. Kocher, ``The TLS protocol,''
Request for Comments XXXX, Internet Engineering Task Force,
Feb. 1998.
8 J. Franks, P. Hallam-Baker, and J. Hostetler, ``An extension to
HTTP: digest access authentication,'' RFC 2069, Internet HTTP: digest access authentication,'' RFC 2069, Internet
Engineering Task Force, Jan. 1997. Engineering Task Force, Jan. 1997.
7 J. Postel, ``User datagram protocol,'' RFC STD 6, 768, Internet 9 J. Postel, ``User datagram protocol,'' RFC STD 6, 768, Internet
Engineering Task Force, Aug. 1980. Engineering Task Force, Aug. 1980.
8 B. Hinden and C. Partridge, ``Version 2 of the reliable data 10 B. Hinden and C. Partridge, ``Version 2 of the reliable data
protocol (RDP),'' RFC 1151, Internet Engineering Task Force, protocol (RDP),'' RFC 1151, Internet Engineering Task Force,
Apr. 1990. Apr. 1990.
9 J. Postel, ``Transmission control protocol,'' RFC STD 7, 793, 11 J. Postel, ``Transmission control protocol,'' RFC STD 7, 793,
Internet Engineering Task Force, Sept. 1981. Internet Engineering Task Force, Sept. 1981.
10 H. Schulzrinne, ``A comprehensive multimedia control 12 H. Schulzrinne, ``A comprehensive multimedia control
architecture for the Internet,'' in Proc. International architecture for the Internet,'' in Proc. International
Workshop on Network and Operating System Support for Digital Workshop on Network and Operating System Support for Digital
Audio and Video (NOSSDAV), (St. Louis, Missouri), May 1997. Audio and Video (NOSSDAV), (St. Louis, Missouri), May 1997.
11 P. McMahon, ``GSS-API authentication method for SOCKS version 13 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.
14 P. McMahon, ``GSS-API authentication method for SOCKS version
5,'' RFC 1961, Internet Engineering Task Force, June 1996. 5,'' RFC 1961, Internet Engineering Task Force, June 1996.
12 J. Miller, P. Resnick, and D. Singer, ``Rating services and 15 J. Miller, P. Resnick, and D. Singer, ``Rating services and
rating systems (and their machine readable descriptions),'' rating systems (and their machine readable descriptions),''
Recommendation REC-PICS-services-961031, W3C (World Wide Web Recommendation REC-PICS-services-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996. Consortium), Boston, Massachusetts, Oct. 1996.
13 J. Miller, T. Krauskopf, P. Resnick, and W. Treese, ``PICS 16 J. Miller, T. Krauskopf, P. Resnick, and W. Treese, ``PICS
label distribution label syntax and communication protocols,'' label distribution label syntax and communication protocols,''
Recommendation REC-PICS-labels-961031, W3C (World Wide Web Recommendation REC-PICS-labels-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996. Consortium), Boston, Massachusetts, Oct. 1996.
14 D. Crocker and P. Overell, ``Augmented BNF for syntax 17 D. Crocker and P. Overell, ``Augmented BNF for syntax
specifications: ABNF,'' RFC 2234, Internet Engineering Task specifications: ABNF,'' RFC 2234, Internet Engineering Task
Force, Nov. 1997. Force, Nov. 1997.
15 R. Elz, ``A compact representation of IPv6 addresses,'' RFC 18 B. Braden, ``Requirements for internet hosts - application and
support,'' RFC STD 3, 1123, Internet Engineering Task Force,
Oct. 1989.
19 R. Elz, ``A compact representation of IPv6 addresses,'' RFC
1924, Internet Engineering Task Force, Apr. 1996. 1924, Internet Engineering Task Force, Apr. 1996.
16 T. Berners-Lee, L. Masinter, and M. McCahill, ``Uniform 20 T. Berners-Lee, L. Masinter, and M. McCahill, ``Uniform
resource locators (URL),'' RFC 1738, Internet Engineering Task resource locators (URL),'' RFC 1738, Internet Engineering Task
Force, Dec. 1994. Force, Dec. 1994.
17 International Telecommunication Union, ``Visual telephone 21 F. Yergeau, ``Utf-8, a transformation format of iso 10646,''
systems and equipment for local area networks which provide a Request for Comments XXXX, Internet Engineering Task Force,
non-guaranteed quality of service,'' Recommendation H.323, Jan. 1998.
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, May 1996.
18 W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2. 22 B. Braden, ``T/TCP - TCP extensions for transactions functional
specification,'' RFC 1644, Internet Engineering Task Force,
July 1994.
23 W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2.
Reading, Massachusetts: Addison-Wesley, 1994. Reading, Massachusetts: Addison-Wesley, 1994.
19 H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 24 H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
``RTP: a transport protocol for real-time applications,'' RFC ``RTP: a transport protocol for real-time applications,'' RFC
1889, Internet Engineering Task Force, Jan. 1996. 1889, Internet Engineering Task Force, Jan. 1996.
20 R. Fielding, ``Relative uniform resource locators,'' RFC 1808, 25 R. Fielding, ``Relative uniform resource locators,'' RFC 1808,
Internet Engineering Task Force, June 1995. Internet Engineering Task Force, June 1995.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved. Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
 End of changes. 

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