names and values used in this appendix are to be used as defined in
SDP (RFC2327 [6]):
C.1.1 Control URL
The "a=control:" attribute is used to convey the control URL. This
attribute is used both for the session and media descriptions. If
used for individual media, it indicates the URL to be used for
controlling that particular media stream. If found at the session
level, the attribute indicates the URL for aggregate control.
Example:
a=control:rtsp://example.com/foo
This attribute may contain either relative and absolute URLs,
following the rules and conventions set out in RFC1808 [25].
Implementations should look for a base URL in the following order:
1. The RTSP Content-Base field
2. The RTSP Content-Location field
3. The RTSP request URL
If this attribute contains only an asterisk (*), then the URL is
treated as if it were an empty embedded URL, and thus inherits the
entire base URL.
C.1.2 Media streams
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 unicast, the port number serves as
a recommendation from the server to the client; the client still has
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 to zero.
Example:
m=audio 0 RTP/AVP 31
C.1.3 Payload type(s)
The payload type(s) are specified in the "m=" field. In case the
payload type is a static payload type from RFC1890 [1], no other
information is 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 RFC1890 (Sections 5 and 6), or an experimental encoding
with a "X-" prefix as specified in SDP (RFC2327 [6]). Codec-
specific parameters are not specified in this field, but rather in
the "fmtp" attribute described below. Implementors seeking to
register new encodings should follow the procedure in RFC1890 [1].
If the media type is not suited to the RTP AV profile, then it is
recommended that a new profile be created and the appropriate profile
name be used in lieu of "RTP/AVP" in the "m=" field.
C.1.4 Format-specific parameters
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 the packetization
interval is conveyed using the "ptime" attribute.
C.1.5 Range of presentation
The "a=range" attribute defines the total time range of the stored
session. (The length of live sessions can be deduced from the "t" and
"r" parameters.) Unless the presentation contains media streams of
different durations, the range attribute is a session-level
attribute. The unit is specified first, followed by the value range.
The units and their values are as defined in Section 3.5, 3.6 and
3.7.
Examples:
a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203
C.1.6 Time of availability
The "t=" field MUST contain suitable values for the start and stop
times for both aggregate and non-aggregate stream control. With
aggregate 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. With non-aggregate control, the
values should reflect the actual period for which the session is
available in keeping with SDP semantics, and not depend on other
means (such as the life of the web page containing the description)
for this purpose.
C.1.7 Connection Information
In SDP, the "c=" field contains the destination address for the media
stream. However, for on-demand unicast streams and some multicast
streams, the destination address is specified by the client via the
SETUP request. Unless the media content has a fixed destination
address, the "c=" field is to be set to a suitable null value. For
addresses of type "IP4", this value is "0.0.0.0".
C.1.8 Entity Tag
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 section 12.22) 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.
Example:
a=etag:158bb3e7c7fd62ce67f12b533f06b83a
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.
C.2 Aggregate Control Not Available
If a presentation does not support aggregate control and multiple
media sections are specified, each section MUST have the control URL
specified via the "a=control:" attribute.
Example:
v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I came from a web page
t=0 0
c=IN IP4 0.0.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
Note that the position of the control URL in the description implies
that the client establishes separate RTSP control sessions to the
servers audio.com and video.com.
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.
C.3 Aggregate Control Available
In this scenario, the server has multiple streams that can be
controlled as a whole. In this case, there are both media-level
"a=control:" attributes, which are used to specify the stream URLs,
and a session-level "a=control:" attribute which is used as the
request URL for aggregate control. If the media-level URL is
relative, it is resolved to absolute URLs according to Section C.1.1
above.
If the presentation comprises only a single stream, the media-level
"a=control:" attribute may be omitted altogether. However, if the
presentation contains more than one stream, each media stream section
MUST contain its own "a=control" attribute.
Example:
v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I contain
i=<more info>
t=0 0
c=IN IP4 0.0.0.0
a=control:rtsp://example.com/movie/
m=video 8002 RTP/AVP 31
a=control:trackID=1
m=audio 8004 RTP/AVP 3
a=control:trackID=2
In this example, the client is required to establish a single RTSP
session to the server, and uses the URLs
rtsp://example.com/movie/trackID=1 and
rtsp://example.com/movie/trackID=2 to set up the video and audio
streams, respectively. The URL rtsp://example.com/movie/ controls the
whole movie.
Appendix D: Minimal RTSP implementation
D.1 Client
A client implementation MUST be able to do the following :
* Generate the following requests: SETUP, TEARDOWN, and one of PLAY
(i.e., a minimal playback client) or RECORD (i.e., a minimal
recording client). If RECORD is implemented, ANNOUNCE must be
implemented as well.
* Include the following headers in requests: CSeq, Connection,
Session, Transport. If ANNOUNCE is implemented, the capability to
include headers Content-Language, Content-Encoding, Content-
Length, and Content-Type should be as well.
* Parse and understand the following headers in responses: CSeq,
Connection, Session, Transport, Content-Language, Content-
Encoding, Content-Length, Content-Type. If RECORD is implemented,
the Location header must be understood as well. RTP-compliant
implementations should also implement RTP-Info.
* Understand the class of each error code received and notify the
end-user, if one is present, of error codes in classes 4xx and
5xx. The notification requirement may be relaxed if the end-user
explicitly does not want it for one or all status codes.
* Expect and respond to asynchronous requests from the server, such
as ANNOUNCE. This does not necessarily mean that it should
implement the ANNOUNCE method, merely that it MUST respond
positively or negatively to any request received from the server.
Though not required, the following are highly recommended at the time
of publication for practical interoperability with initial
implementations and/or to be a "good citizen".
* Implement RTP/AVP/UDP as a valid transport.
* Inclusion of the User-Agent header.
* Understand SDP session descriptions as defined in Appendix C
* Accept media initialization formats (such as SDP) from standard
input, command line, or other means appropriate to the operating
environment to act as a "helper application" for other
applications (such as web browsers).
There may be RTSP applications different from those initially
envisioned by the contributors to the RTSP specification for which
the requirements above do not make sense. Therefore, the
recommendations above serve only as guidelines instead of strict
requirements.
D.1.1 Basic Playback
To support on-demand playback of media streams, the client MUST
additionally be able to do the following:
* generate the PAUSE request;
* implement the REDIRECT method, and the Location header.
D.1.2 Authentication-enabled
In order to access media presentations from RTSP servers that require
authentication, the client MUST additionally be able to do the
following:
* recognize the 401 status code;
* parse and include the WWW-Authenticate header;
* implement Basic Authentication and Digest Authentication.
D.2 Server
A minimal server implementation MUST be able to do the following:
* Implement the following methods: SETUP, TEARDOWN, OPTIONS and
either PLAY (for a minimal playback server) or RECORD (for a
minimal recording server). If RECORD is implemented, ANNOUNCE
should be implemented as well.
* Include the following headers in responses: Connection,
Content-Length, Content-Type, Content-Language, Content-Encoding,
Transport, Public. The capability to include the Location header
should be implemented if the RECORD method is. RTP-compliant
implementations should also implement the RTP-Info field.
* Parse and respond appropriately to the following headers in
requests: Connection, Session, Transport, Require.
Though not required, the following are highly recommended at the time
of publication for practical interoperability with initial
implementations and/or to be a "good citizen".
* Implement RTP/AVP/UDP as a valid transport.
* Inclusion of the Server header.
* Implement the DESCRIBE method.
* Generate SDP session descriptions as defined in Appendix C
There may be RTSP applications different from those initially
envisioned by the contributors to the RTSP specification for which
the requirements above do not make sense. Therefore, the
recommendations above serve only as guidelines instead of strict
requirements.
D.2.1 Basic Playback
To support on-demand playback of media streams, the server MUST
additionally be able to do the following:
* Recognize the Range header, and return an error if seeking is not
supported.
* Implement the PAUSE method.
In addition, in order to support commonly-accepted user interface
features, the following are highly recommended for on-demand media
servers:
* Include and parse the Range header, with NPT units.
Implementation of SMPTE units is recommended.
* Include the length of the media presentation in the media
initialization information.
* Include mappings from data-specific timestamps to NPT. When RTP
is used, the rtptime portion of the RTP-Info field may be used to
map RTP timestamps to NPT.
Client implementations may use the presence of length information
to determine if the clip is seekable, and visibly disable seeking
features for clips for which the length information is unavailable.
A common use of the presentation length is to implement a "slider
bar" which serves as both a progress indicator and a timeline
positioning tool.
Mappings from RTP timestamps to NPT are necessary to ensure correct
positioning of the slider bar.
D.2.2 Authentication-enabled
In order to correctly handle client authentication, the server MUST
additionally be able to do the following:
* Generate the 401 status code when authentication is required for
the resource.
* Parse and include the WWW-Authenticate header
* Implement Basic Authentication and Digest Authentication
Appendix E: Authors' Addresses
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
Anup Rao
Netscape Communications Corp.
501 E. Middlefield Road
Mountain View, CA 94043
USA
EMail: anup@netscape.com
Robert Lanphier
RealNetworks
1111 Third Avenue Suite 2900
Seattle, WA 98101
USA
EMail: robla@real.com
Appendix F: Acknowledgements
This memo is based on the functionality of the original RTSP document
submitted in October 96. It also borrows format and descriptions from
HTTP/1.1.
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:
Rahul Agarwal, 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, John K. Ho, Philipp Hoschka,
Anne Jones, Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan
Lennox, Eduardo F. Llach, Rob McCool, David Oran, Maria Papadopouli,
Sujal Patel, Ema Patki, Alagu Periyannan, Igor Plotnikov, Pinaki
Shah, David Singer, Jeff Smith, Alexander Sokolsky, Dale Stammen, and
John Francis Stracke.
References
1 Schulzrinne, H., "RTP profile for audio and video conferences
with minimal control", RFC1890, January 1996.
2 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext transfer protocol - HTTP/1.1", RFC
2068, January 1997.
3 Yergeau, F., Nicol, G., Adams, G., and M. Duerst,
"Internationalization of the hypertext markup language", RFC
2070, January 1997.
4 Bradner, S., "Key words for use in RFCs to indicate
requirement levels", BCP 14, RFC2119, March 1997.
5 ISO/IEC, "Information technology - generic coding of moving
pictures and associated audio information - 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.
6 Handley, M., and V. Jacobson, "SDP: Session Description
Protocol", RFC2327, April 1998.
7 Franks, J., Hallam-Baker, P., and J. Hostetler, "An extension to
HTTP: digest access authentication", RFC2069, January 1997.
8 Postel, J., "User Datagram Protocol", STD 6, RFC768, August
1980.
9 Hinden, B. and C. Partridge, "Version 2 of the reliable data
protocol (RDP)", RFC1151, April 1990.
10 Postel, J., "Transmission control protocol", STD 7, RFC793,
September 1981.
11 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.
12 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.
13 McMahon, P., "GSS-API authentication method for SOCKS version
5", RFC1961, June 1996.
14 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.
15 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.
16 Crocker, D. and P. Overell, "Augmented BNF for syntax
specifications: ABNF", RFC2234, November 1997.
17 Braden, B., "Requirements for internet hosts - application and
support", STD 3, RFC1123, October 1989.
18 Elz, R., "A compact representation of IPv6 addresses", RFC
1924, April 1996.
19 Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
resource locators (URL)", RFC1738, December 1994.
20 Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC2279, January 1998.
22 Braden, B., "T/TCP - TCP extensions for transactions
functional specification", RFC1644, July 1994.
22 W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2.
Reading, Massachusetts: Addison-Wesley, 1994.
23 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: a transport protocol for real-time applications", RFC
1889, January 1996.
24 Fielding, R., "Relative uniform resource locators", RFC1808,
June 1995.
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.