INTERNET-DRAFT                   Henning Schulzrinne, Columbia University
                                        Anup Rao, Netscape Communications
                                       Rob Lanphier, Progressive Networks
SUBMITTED: 26th November 1996 24th February 1997                   Expires: 26th May 24th August 1997

                    Real Time Streaming Protocol (RTSP)
		   <draft-ietf-mmusic-rtsp-00.txt>
                       draft-ietf-mmusic-rtsp-01.txt

STATUS OF THIS MEMO

This is an Internet-Draft. Internet-Drafts are working documents of the
Internet Engineering Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), mannari.oz.au
(Pacific Rim), ds.internic.net (Us East Coast), or ftp.isi.edu (US West
Coast).

Prior to the expiration of this draft, the list of open issues may be found
at the following URL:

http://www.prognet.com/prognet/ra/openissues.html

This contains a list of issues that have been discussed on the MMUSIC
mailing list (confctrl).  Many of the points brought up have a rather
holistic effect on the whole document (such as discussions of
converting the protocol to a text-based protocol, or breaking this
draft up into several drafts), while other have rather localized
effect (Appendix C changes).  The points that are localized will be
be pointed out in various parts of this draft.

ABSTRACT

http://www.prognet.com/prognet/rt/openissues.html

Abstract:

The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for control over the delivery of data with real-time properties. RTSP
provides an extensible framework to enable controlled, on-demand delivery
of real- time real-time data, such as audio and video. Sources of data can include
both live data feeds and stored clips. This protocol is intended to control
multiple data delivery sessions, provide a means for choosing delivery
channels such as UDP, multicast UDP and TCP, and delivery mechanisms based
upon RTP (RFC 1889). RTSP uses the Session Control Protocol (SCP) (see appendix) to
allow the use of a single TCP connection between the client and
server for controlling delivery of one or more streams of data.

H. Schulzrinne, A. Rao, R. Lanphier                            Page  1

[Note: see "Use Of UDP For Delivery Of Control Messages" in the "Open
Issues" document for discussion of alternative control delivery
(http://www.prognet.com/prognet/rt/openissues.html)]

TABLE OF CONTENTS

     1.0 INTRODUCTION
     2.0 DOCUMENT CONVENTIONS
     3.0 PROTOCOL DESCRIPTION

Contents

   * 1 Introduction
        o 1.1 Purpose
        o 1.2 Requirements
        o 1.3 Terminology
        o 1.4 Protocol Properties
        o 1.5 Extending RTSP
        o 1.6 Overall Operation
        o 1.7 RTSP States
        o 1.8 Relationship with Other Protocols
   * 2 Notational Conventions
   * 3 Protocol Parameters
        o 3.1 Connection Messages RTSP Version
        o 3.2 Object Messages RTSP URL
        o 3.3 Custom Messages/Events Conference Identifiers
        o 3.4 Media specific options and Extension mechanism
     4.0 EXAMPLES/APPLICATION NOTE
     5.0 REFERENCES
     6.0 APPENDIXES Relative Timestamps
        o 3.5 Absolute Time
   * 4 RTSP Message
        o 4.1 Message Types
        o 4.2 Message Headers
        o 4.3 Message Body
        o 4.4 Message Length
   * 5 Request
   * 6 Response
        o 6.1 Appendix A - Status-Line
             + 6.1.1 Status Code and Reason Phrase
             + 6.1.2 Response Header Fields
   * 7 Entity
        o 7.1 Entity Header Fields
        o 7.2 Entity Body
   * 8 Connections
        o 8.1 Pipelining
        o 8.2 Reliability and Acknowledgements
   * 9 Method Definitions
        o 9.1 HELLO
        o 9.2 GET
        o 9.3 SETUP
        o 9.4 PLAY
        o 9.5 PAUSE
        o 9.6 CLOSE
        o 9.7 BYE
        o 9.8 GET_PARAMETER
        o 9.9 SET_PARAMETER
        o 9.10 REDIRECT
        o 9.11 SESSION
        o 9.12 RECORD
        o 9.13 Embedded Binary Data Packets
          6.2 Appendix B -

H. Schulzrinne, A. Rao, R. Lanphier                            Page  2
   * 10 Status Codes Definitions
        o 10.1 Client Error 4xx
             + 10.1.1 451 Parameter Not Understood
             + 10.1.2 452 Conference Not Found
             + 10.1.3 453 Not Enough Bandwidth
             + 10.1.4 45x Session Control Protocol (SCP)
          6.3 Appendix Not Found
             + 10.1.5 45x Method Not Valid in This State
             + 10.1.6 45x Header Field Not Valid for Resource
             + 10.1.7 45x Invalid Range
             + 10.1.8 45x Parameter Is Read-Only
   * 11 Header Field Definitions
        o 11.1 Accept
        o 11.2 Accept-Encoding
        o 11.3 Accept-Language
        o 11.4 Allow
        o 11.5 Authorization
        o 11.6 Bandwidth
        o 11.7 Blocksize
        o 11.8 Conference
        o 11.9 Content-Encoding
        o 11.10 Content-Length
        o 11.11 Content-Type
        o 11.12 Date
        o 11.13 If-Modified-Since
        o 11.14 Last-modified
        o 11.15 Location
        o 11.16 Range
        o 11.17 Require
        o 11.18 Unsupported
        o 11.19 Nack-Transport-Require
        o 11.20 Transport-Require
        o 11.21 Retry-After
        o 11.22 Speed
        o 11.23 Server
        o 11.24 Session
        o 11.25 Transport
        o 11.26 User-Agent
        o 11.27 Via
        o 11.28 WWW-Authenticate
   * 12 Caching
   * 13 Examples
        o 13.1 Media on Demand (Unicast)
        o 13.2 Live Media Event Using Multicast
        o 13.3 Playing media into an existing session
        o 13.4 Recording

H. Schulzrinne, A. Rao, R. Lanphier                            Page  3
   * 14 Syntax
        o 14.1 Base Syntax
        o 14.2 Internet Media Type Syntax
        o 14.3 Universal Resource Identifier Syntax
        o 14.4 RTSP-specific syntax
   * 15 Experimental
        o 15.1 Header Field Definitions
             + 15.1.1 Address
   * 16 Security Considerations
   * A State Machines
        o A.1 Client State Machine
             + A.1.1 Client States
             + A.1.2 Notes
             + A.1.3 State Table
        o A.2 Server State Machine
             + A.2.1 Server States
             + A.2.2 State Table
   * B Open Issues
   * C - RTSP Audio Format
          6.4 Appendix Author Addresses
   * D - Acknowledgements
   * References

1 Introduction

1.1 Purpose

RTSP Audio Annotations
          6.5 Appendix E - Authors

1.0 INTRODUCTION

This document describes the Real Time Streaming Protocol, establishes and controls either single or RTSP.

The RTSP provides mechanisms to:
     -Request delivery several (time-synchronized)
streams of real-time data
     -Request a specific transport type and destination for continuous media. It does not typically deliver the delivery continuous
streams itself, although interleaving of the data
     -Request information about continuous media stream with
the data control stream is possible (Section 9.13).

There is no notion of an RTSP connection, but rather a session maintained
by an identifier. An RTSP session is in no way tied to a format-
      specific fashion
     -Start, stop, transport-level
session. During an RTSP session, an RTSP client may open and pause the delivery of close many
reliable transport connections to the data
     -Provide random access server to issue RTSP requests.
Alternatively, it may use a connectionless transport protocol such as UDP.

The protocol is intentionally similar in syntax and operation to HTTP/1.1,
so that extension mechanisms to HTTP can in most cases also be added to various portions
RTSP. However, RTSP differs in a number of the data
      (where applicable) important aspects from HTTP:

H. Schulzrinne, A. Rao, R. Lanphier                            Page  4
   * RTSP uses TCP for delivery introduces a number of control messages, new methods and allows for has a
variety of delivery options for different protocol
     identifier.
   * An RTSP server needs to maintain state by default in almost all cases,
     as opposed to the data including both multicast stateless nature of HTTP. (RTSP servers and
unicast UDP based on RTP(RFC 1889), clients
     MAY use the HTTP state maintenance mechanism [1].)
   * Both an RTSP server and TCP where applicable. client can issue requests.
   * Data is carried out-of-band, by a different protocol. (There is an
     exception to this.)
   * RTSP
uses is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1,
     consistent with current HTML internationalization efforts [2].

          HS: Probably the Session Control Protocol (see appendix) right thing to allow do, but may lead to
          confusion with GET.

   * The Request-URI always contains the use absolute URI. Because of backward
     compatibility with a single TCP connection between historical blunder, HTTP/1.1 carries only the client and server for controlling
delivery of one or more streams of data. The RTSP specifically uses
one SCP session to deliver control messages and
     absolute path in addition, a new
SCP session might be opened for each real-time object delivered.

Rao, Lanphier                                                  Page  2

While the protocol request

          This makes virtual hosting easier. However, this is designed for the streaming of real- time data
regardless
          incompatible with HTTP/1.1, which may be a bad idea. Makes
          definition of its format, GET confusing, if it also provides mechanisms to inquire
about format specific information (compression type, data rate,
compression-type specific headers and frame boundaries).
Considerations for each peer arising from these features are
discussed later is included in RTSP.

The protocol supports the document. Three typical categories following operations:

Retrieval of data
whose delivery could be controlled with RTSP include:

1. Real-time stored clips
This category comprises all real-time recordings (primarily
audio/video).  Examples include web sites with audio narration,
stored audio recordings, media from media server:
     The client can request a session description via HTTP or some other
     method. If the session is being multicast, the session description
     contains the multicast addresses and video recordings. A typical end-user
application would ports to be an audio/video store site providing excerpts
from its collection on-demand.

2. Real-time live feeds
This category comprises real-time data which used for the
     continuous media. If the session is fed in live at to be sent only to the
server site rather than being pre-recorded. Examples client via
     unicast, the client provides the destination for security reasons.

Invitation of this usage
include a press conference, media server to a live internet radio station, conference:
     A media server can be ``invited'' to join an existing conference,
     either to play back media into the session or a
televised shuttle launch.

3. Non real-time stored data
This category comprises non-real-time data of any MIME type, similar to data served by HTTP servers. This data is provided over record all or a new SCP
session. While HTTP servers would serve this kind
     subset of data the media in most
cases, it might be advanta- geous to serve non-real-time data with
RTSP. This is typically true of non-real-time data pertaining to
real- time data being served; for example, a text track playing along
with audio/video. session. This category mode is meant to provide useful for distributed
     teaching applications. Several parties in the capability conference may take
     turns ``pushing the remote control buttons''.

Addition of
serving non-real-time data through RTSP, and media to an existing session:
     Particularly for live events, it is strongly
recommended that it be used only when advantageous over existing
mechanisms.

[Note: Other scenarios that don't fall into useful if the above categories may
be discussed in server can tell the "Open Issues" document
(http://www.prognet.com/prognet/rt/openissues.html)]

2.0 DOCUMENT CONVENTIONS
     client about additional media becoming available.

H. Schulzrinne, A. Rao, R. Lanphier                            Page  5

RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1.

1.2 Requirements

The following conventions are used throughout this document:

Byte Order key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and Alignment
All integer fields
``OPTIONAL'' in this document are carried to be interpreted as described in network byte order, where RFC
xxxx [3].

1.3 Terminology

Some of the most
significant byte is sent first. Integers terminology has been adopted from HTTP/1.1 [4]. Terms not
listed here are aligned on their natural
length: 16 bit integers on even byte boundary, 32 bit integers on 4
byte boundary and so on.

Rao, Lanphier                                                  Page  3

Definitions

Stream
A stream is data of defined as in HTTP/1.1.

Conference:
     a distinct type that is sent from server multiparty, multimedia session, where ``multi'' implies greater than
     or equal to one.

Client:
     The client at a rate defined by requests continuous media data from the server, even if more bandwidth is
available. For a typical video broadcast, media server.

Connection:
     A transport layer virtual circuit established between two programs for example, one stream
could consist of
     the video signal, one stream could consist purpose of the
audio data, communication.

Continuous media:
     Data where there is a timing relationship between source and one stream could contain sink,
     that is, the closed caption
information. In most cases, each stream is served at sink must reproduce the rate timing relationshop that it
should be rendered by existed
     at the client.

Global Control Session source. The SCP session with a well-known session ID, used for exchange of
connection messages described later in this document.

Stream Control Session
An SCP session established for each stream, used for
exchange most common examples of object messages described later in this
document.

URL
A Uniform Resource Locator continuous media are audio
     and motion video. Continuous media can be realtime (interactive),
     where there is a ``tight'' timing relationship between source and
     sink, or URL streaming (playback), where the relationship is less strict.

Entity:
     An entity is a unique identifier
that describes participant in a resource on the Internet. conference. This participant may be
     non-human, e.g., a media record or playback server.

Media server:
     The syntax network entity providing playback or recording services for
URLs is defined by RFC 1738.

3.0 PROTOCOL DESCRIPTION

Two classes of messages exist in RTSP; those sent on the
Global control session, termed connection messages and
those sent on the Stream control session, termed object
messages. Some messages might fall in both categories.

3.1 Connection messages

Connection messages are used to negotiate protocol version and
possibly client identity.  This is common to all one or
     more media streams. Different media streams
requested within a session may
     originate from different media servers. A media server may reside on
     the connection. same or a different host as the web server the media session is
     invoked from.

H. Schulzrinne, A. Rao, R. Lanphier                            Page  4

HELLO

Upon connection, the  6

Media session:
     A collection of media streams to be treated as an aggregate, with a
     single time axis. Typically, a client sends will synchronize in time all
     media streams within a HELLO message to the server
informing it media session. An example of its version a media session is
     a movie consisting of a video and desire to establish audio track.

(Media) stream:
     A single media instance, e.g., an audio stream or a RTSP video stream as
     well as a single whiteboard or shared application group. When using
     RTP, a stream consists of all RTP and RTCP packets created by a source
     within an RTP session. The server replies with

     [TBD: terminology is confusing since there's an RTP session, which is
     used by a HELLO message.  The server
need not wait for the clients HELLO message before sending its
own. single RTSP stream.]

Message:
     The message includes protocol version, and optional
character string denoting basic unit of RTSP communication, consisting of a structured
     sequence of octets matching the user- agent(to be specified). The
communication continues syntax defined in Section 14 and
     transmitted via a connection or a connectionless protocol.

Response:
     An RTSP response. If an HTTP response is meant, that is indicated
     explicitly.

Request:
     An RTSP request. If an HTTP request is meant, that is indicated
     explicitly.

Session description:
     A session description contains information about one or more media
     within a session, such as the lower set of encodings, network addresses and
     information about the exchanged
versions. If the two sides cannot speak this common version, content. The session description may take
     several different formats, including SDP and SDF.

Media parameter:
     Parameter specific to a media type that may be changed while the
connection
     stream is closed.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         HELLO                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Major     |     Minor     | Sub being played or prior to it.

1.4 Protocol  |     Reserved  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                      User Agent (Optional)                    /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Major Version
Specifies the major RTSP version.

Minor Version
Specifies the minor Properties

RTSP version within the major version.

Sub Protocol
Specifies the sub-protocol spoken by has the sender. For normal
client-server communication, this should following properties:

Extendable:
     New methods and parameters can be 0.

Reserved
For future use.

User Agent
Is an optional null-terminated character string sent by the
client easily added to provide information like the client name, machine type,
OS etc. RTSP.

H. Schulzrinne, A. Rao, R. Lanphier                            Page  5

ID

This message is sent  7

Easy to parse:
     RTSP can be parsed by standard HTTP or MIME parsers.

Secure:
     RTSP re-uses web security mechanisms, either a server at the transport level
     (TLS [5]) or a client. The
recipient of this message is asked to prove its identity. A
number of different schemes are possible, within the simplest of which
uses a password. More complicated schemes can cause a one time
challenge protocol itself. All HTTP authentication
     mechanisms such as basic [4, Section 11.1,] and response mechanism. Multiple challenge response
steps digest authentication
     [6] are possible and implemenation dependent.

A separate ID message allows directly applicable.

Transport-independent:
     RTSP may use either an unreliable datagram protocol (UDP) [7], a server to service
     reliable datagram protocol (RDP, not widely used [8]) or a reliable
     stream protocol such as TCP [9] as it implements application-level
     reliability.

Multi-server capable:
     Each media stream within a session can reside on a number of different classes of users. server.
     The ID message can be sent client automatically establishes several concurrent control
     sessions with the different media servers. Media synchronization is
     performed at any
time during the session or may be sent once per URL, depending on
how transport level.

Control of recording devices:
     The protocol can control both recording and playback devices, as well
     as devices that can alternate between the two modes (``VCR'').

Separation of stream control and conference initiation:
     Stream control is divorced from inviting a media server to a service
     conference. The only requirement is configured.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          tag(ID)                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            key type           |           (reserved)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                      authentication key                       /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key type
Specifies that the authentication key type. Authentication of
different strengths might conference initiation
     protocol either provides or can be required in different
situations. This field allows used to create a choice of authentication. It is
up unique conference
     identifier. In particular, SIP [10] or H.323 may be used to the client and invite a
     server to negotiate what level a conference.

Suitable for professional applications:
     RTSP supports frame-level accuracy through SMPTE time stamps to allow
     remote digital editing.

Session description neutral:
     The protocol does not impose a particular session description or
     metafile format and can convey the type of
authentication is used. Note that different services might format to be
available at different authentication levels.

Authentication key
Specifies the key that authenticates used. However,
     the sender. The standard key
types session description must contain an RTSP URI.

Proxy and proper responses will firewall friendly:
     The protocol should be specified in an extension to
this document.

ID_RESP
This message is sent in response readily handled by both application and
     transport-layer (SOCKS [11]) firewalls. A firewall may need to an ID message. The entity
issuing the ID message closes
     understand the TCP connection if SETUP method to open a ``hole'' for the response
is not valid. UDP media
     stream.

H. Schulzrinne, A. Rao, R. Lanphier                            Page  6
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7  8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          tag(ID_RESP)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            key type           |          response code        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                         response data                         /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key type
Specifies

HTTP-friendly:
     Where sensible, RTSP re-uses HTTP concepts, so that the authentication key type. Authentication of
different strength may existing
     infrastructure can be required in different situations. re-used. This
field allows a choice of authentication. It is up infrastructure includes JEPI (the
     Joint Electronic Payment Initiative) for electronic payments and PICS
     (Platform for Internet Content Selection) for associating labels with
     content. However, RTSP does not just add methods to HTTP, since the client
and
     controlling continuous media requires server state in most cases.

Appropriate server control:
     If a client can start a stream, it must be able to negotiate what level of authentication is used.
Note stop a stream.
     Servers should not start streaming to clients in such a way that different services might be available at different
authentication levels.

Response code
Specifies one of
     clients cannot stop the two possible responses stream.

Transport negotiation:
     The client can negotiate the transport method prior to an ID message:
     OK
     Authentication type recognized, response follows.

     UNKNOWN
     Unknown type, ordered list of authentication types follows
     (can be actually
     needing to process a null list).

Response data
Specifies continuous media stream.

Capability negotiation:
     If basic features are disabled, there must be some clean mechanism for
     the response, depending on client to determine which methods are not going to be implemented.
     This allows clients to present the response code. If OK,
then this appropriate user interface. For
     example, if seeking is not allowed, the key user interface must be able to
     disallow moving a sliding position indicator.

     An earlier requirement in RTSP' was multi-client capability.
     However, it was determined that a better approach was to make
     sure that authenticates the sender, and the
format protocol is dictated easily extensible to the multi-client
     scenario. Stream identifiers can be used by several control
     streams, so that ``passing the authentication type. If UNKNOWN, then remote'' would be possible. The
     protocol would not address how several clients negotiate access;
     this is left to either a list ``social protocol'' or some other floor
     control mechanism.

1.5 Extending RTSP

RTSP can be extended in three ways, listed in order of 16-bit response types that are acceptable to
the recipient.

The standard key types and proper responses will be specified in
an extension to this document.

REDIRECT

A redirect message informs the client that it must connect to
another server location. When received on the Global control
session, it should magnitude of
changes supported:

H. Schulzrinne, A. Rao, R. Lanphier                            Page  9
   * Existing methods can be made effective extended with new parameters, as specified long as these
     parameters can be safely ignored by offset. The
message the recipient. (This is equivalent
     to adding new parameters to an HTML tag.)
   * New methods can also be sent on a Stream control session, in which
case it added. If the recipient of the message does not
     understand the request, it relative to responds with error code 501 (Not
     implemented) and the stream.

Rao, Lanphier                                                  Page  7
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                         tag (REDIRECT)                        |
+-------------------------------+-------------------------------+
|                             Offset                            |
+-------------------------------+-------------------------------+
|                                                               |
/                              URL                              /
|                                                               |
+-------------------------------+-------------------------------+

Offset
On sender can then attempt an earlier, less
     functional version.
   * A new version of the Stream control session, specifies protocol can be defined, allowing almost all
     aspects (except the position (in
milliseconds) in of the protocol version number) to
     change.

1.6 Overall Operation

Each media stream at which time and session may be identified by an RTSP URL. The overall
session and the
redirection is effective. If received on properties of the global control
session, it means that media the server session is not available after
this time.

URL
Is made up of are
defined by a null-terminated string that identifies the new location for session description file, the object. This URL format of which is similar to the one specified in outside the
original FETCH request, described later in
scope of this document.

OPTIONS

This message specification. The session description file is used to negotiate additional functionality. This
can be sent by retrieved
using HTTP, either from the client web server or the server. This is provided as media server, typically using
an
extension mechanism to extend URL with scheme HTTP.

The session description file contains a description of the protocol without changing media streams
making up the
version number. Set 0 refers media session, including their encodings, language, and other
parameters that enable the client to choose the global set most appropriate
combination of options, a
universally-agreed upon set. Implementors can use media. In this session description, each media stream is
identified by an RTSP URL, which points to
negotiate replacements for messages in the current specification;
however, all implementations must be able to support media server handling that
particular media stream and names the core
messages defined here, stream stored on that server. Several
media streams can be located on different servers; for example, audio and
video tracks can be prepared not to use split across servers for load sharing. The description
also enumerates which transport methods the server is capable of. If
desired, the session description can also contain only an option
should RTSP URL, with
the other implementation not complete session description retrieved via RTSP.

Besides the media parameters, the network destination address and port need
to be prepared determined. Several modes of operation can be distinguished:

Unicast:
     The media is transmitted to support the
given option. The maximum size source of an option set the RTSP request, with the
     port number picked by the client. Alternatively, the media is 64.
     transmitted on the same reliable stream as RTSP.

Multicast, server chooses address:
     The media server picks the multicast address and port. This is defined the
     typical case for a live or near-media-on-demand transmission.

Multicast, client chooses address:
     If the server is to participate in an existing multicast conference,
     the spirit of multicast address, port and encryption key are given by the TELNET protocol (RFC 854),
     conference description, established by means outside the scope of this
     specification.

1.7 RTSP States

RTSP controls a stream which provides may be sent via a further explanation separate protocol,
independent of how different
implementations the control channel. For example, RTSP control may interoperate using this mechanism.

Rao, Lanphier                                                  Page  8
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         tag (OPTIONS)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          option set                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     highest option number                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|s.d.s.w|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option set
Implementors can specify an option set to use for adding custom
extensions.  In addition, as occur on
a TCP connection while the protocol matures, certain
options data flows via UDP. Thus, data delivery
continues even if no RTSP requests are received by the media server. Also,
during its lifetime, a single media stream may be accepted as universal controlled by RTSP
requests issued sequentially on different TCP connections. Therefore, the
server needs to maintain ``session state'' to all clients,which will be
placed in the reserved range of option sets. The following ranges
of options are reserved:

Option set                    Purpose
-----------                   ------------------------------------

0                             This is able to correlate RTSP
requests with a universally accepted set
                              of options

0x1-0xFFFF                    Reserved for later allocation

0x10000-0xFFFFFFFF            Custom extensions (i.e. vendor or
                              organization specific)

Highest option number
Specifies the highest option number stream.

     HS: This does not imply that is set or unset. It is
used to calculate the length of the bit vectors that follow. This
list is zero indexed.

Rao, Lanphier                                                  Page  9

s.d.s.w
                                            s.d.s.w
                                            ^ ^ ^ ^
                                            | | | |
                 select do/don't  ----------+ | | |
                 do/don't  -------------------+ | |
                 select will/won't  ------------+ |
                 will/won't  ---------------------+

select do/don't
If set, activates protocol has to be stateful in
     the do/don't flag

do/don't way described here. If set to 1, means DO and if set state were to 0, means DON'T.

DO indicates the request that be defined by identifier
     only, the other party perform, first PLAY or
confirmation RECORD request would initiate stream
     flow, with no need for SETUP. It has been argued that you are expecting a separate
     setup simplifies the other party life of firewall writers.

Many methods in RTSP do not contribute to perform,
the indicated option.

DON'T indicates the demand that the other party stops performing,
or confirmation that you state. However, there are no longer expecting four
that play a central role in defining the other party
to perform, the indicated option.

select will/won't
If set, activates the will/won't flag

will/won't
1 means WILL, 0 means WON'T.

WILL indicates the desire to begin performing, or confirmation
that allocation and usage of stream
resources on the indicated options server: SETUP, PLAY, PAUSE, and CLOSE. The roles they play
are being used.

WON'T indicates defined as follows.

 Step session allocation method  session control method
 1    SETUP
 2                               PLAY
 3                               PAUSE
 4    CLOSE

 SETUP Causes the refusal server to perform, or continue performing,
the indicated option.

At allocate resources for a stream.
 PLAY  Starts data transmission on a stream allocated via SETUP.
 PAUSE Temporarily halts a minimum, stream, without freeing server resources.

 CLOSE Frees resources associated with the response stream. The session ceases to
       exist on the server.

A client must issue a OPTION SETUP request unless all necessary transport
information is to reply already available.

1.8 Relationship with Other Protocols

RTSP has some overlap in functionality with HTTP. It also may interact with
HTTP in that the
desire initial contact with streaming content is often to perform NONE of the requested options. be made
through a web page. The Working Group or IETF needs current protocol specification aims to define allow
different hand-off points between a web server and regulate the
registration process for OPTIONS sets. Currently, no sets are
defined.

GOODBYE
Sent only media server
implementing RTSP. For example, the session description can be retrieved
using HTTP or RTSP. Having the session description be returned by the client web
server makes it possible to politely close have the web server take care of authentication
and billing, by handing out a session description whose media identifier
includes an encrypted version of the requestor's IP address and a
timestamp, with a shared secret between web and media server.

However, RTSP session.

The differs fundamentally from HTTP in that data delivery takes
place out-of-band, in a different protocol. HTTP is an asymmetric protocol,
where the client sends this message to issues requests and the server to indicate that it
is done with its responds. In RTSP, both the
media client and media server can issue requests. RTSP requests are also
not stateless, in that they may set parameters and wants continue to terminate control a
media stream long after the session.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                         tag (GOODBYE)                         |
+-------------------------------+-------------------------------+

3.2 OBJECT MESSAGES

These messages request has been acknowledged.

     Re-using HTTP functionality has advantages in at least two areas,
     namely security and proxies. The requirements are sent on very similar,
     so having the stream control session (one of
which exists for  each stream). They a used ability to request objects,
set transport mechanism, adopt HTTP work on caches, proxies and control data delivery.

FETCH
This
     authentication is valuable.

While most real-time media will use RTP as a transport protocol, RTSP is
not tied to RTP.

RTSP assumes the first message sent on existence of a new stream control session.
It requests an object session description format that can express
both static and temporal properties of a given name. If media session containing several
media streams.

2 Notational Conventions

Since many of the object exists, definitions and syntax are identical to HTTP/1.1, this
specification only points to the client section where they are defined rather than
copying it. For brevity, [HX.Y] is permitted to access it, be taken to refer to Section X.Y of
the server accepts current HTTP/1.1 specification (RFC 2068).

All the
request mechanisms specified in this document are described in both prose
and sends a STREAM_HEADER message an augmented Backus-Naur form (BNF) similar to the client. If the
object is non-existent or access is not allowed, the appro-
priate error message that used in RFC 2068
[H2.1]. It is sent described in detail in [12].

In this draft, we use indented and smaller-type paragraphs to provide
background and motivation. Some of these paragraphs are marked with HS, AR
and RL, designating opinions and comments by the client. individual authors which
may not be shared by the co-authors and require resolution.

3 Protocol Parameters

3.1 RTSP Version

[H3.1] applies, with HTTP replaced by RTSP.

3.2 RTSP URL

The client uses this message ``rtsp'' and ``rtspu'' schemes are used to request an object (for example,
an audio clip) from refer to network resources
via the server. The object is specified as an URL.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                          tag (FETCH)                          |
+-------------------------------+-------------------------------+
|                    Bandwidth (Bits per second)                |
+-------------------------------+-------------------------------+
|          Max Number of Hops   |     Request Flags       |F|M|N|
+-------------------------------+-------------------------------+
|                                                               |
/                       URL (null-terminated)                   /
|                                                               |
+-------------------------------+-------------------------------+

Bandwidth
Specifies RTSP protocol. This section defines the client's estimate scheme-specific syntax and
semantics for RTSP URLs.

  rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [abs_path]
  host     = <A legal Internet host domain name of the bandwidth IP address
             (in bits per
sec) it has available for a particular stream. The exact bit rate dotted decimal form), as defined by Section 2.1
             of the stream RFC 1123>
  port     = *DIGIT

abs_path is provided by defined in [H3.2.1].

     Note that fragment and query identifiers do not have a
     well-defined meaning at this time, with the STREAM_HEADER message from interpretation left
     to the RTSP server. If the server refuses

The scheme rtsp requires that commands are issued via a reliable protocol
(within the request based on insufficient
bandwidth, then Internet, TCP), while the server sends scheme rtspu identifies an unreliable
protocol (within the appropriate error message.

Max Number of Hops
Specifies Internet, UDP).

If the maximum number of hops. A hop port is a connection
between Client, Server empty or Proxy. For example, the not given, port 554 is assumed. The semantics are three hops
for passing through two proxies and connecting to a server. If
set to 0xFFFF, then
that the number of hops is unlimited.

Request Flags
   F - Fresh bit, used to override Proxy Cache
   M - Multicast capable
   N - No Rate (rate unlimited file transfer, used only for TCP.
This could identified resource can be used controlled be RTSP at the server
listening for transfering non-real time data, such as
metafiles)

URL - Universal Resource Locator

Specifies a null-terminated string which identifies TCP (scheme ``rtsp'') connections or UDP (scheme ``rtspu'')
packets on that port of host, and the
location Request-URI for the object (i.e. RTSP://host-name:port/filename)

STREAM_HEADER

This message resource is sent
rtsp_URL.

The use of IP addresses in response to a successful FETCH message.
It provides the basic information about URLs SHOULD be avoided whenever possible (see
RFC 1924 [13]).

A media presentation is identified by an textual media identifier, using
the stream such as rate,
generic type, character set and last modification time.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                        tag (STREAM_HEADER)                    |
+-------------------------------+-------------------------------+
|                       Generic Type (family)                   |
+-------------------------------+-------------------------------+
|                    Bit Rate (Bits per second)                 |
+-------------------------------+-------------------------------+
|                     Last Modification Time                    |
+-------------------------------+-------------------------------+
|                           Reserved                            |
+-------------------------------+-------------------------------+
|                      Length (milliseconds)                    |
+-------------------------------+-------------------------------+
|                      Max Packet size (bytes)                  |
+---------------+---------------+---------------+---------------+
|                       Flags                      x|L|C|H|A|U|M|
+---------------+---------------+---------------+---------------+

Generic type (family)
Specifies the type escape conventions [H3.2] of family, such as RTSP_Audio, etc. Currently,
RTSP_Audio is defined URLs []. Requests
described in Section 9 can refer to either the appendix.

Bandwidth
Specifies the rate whole presentation or bandwidth an
individual track within the presentation. Note that some methods can only
be applied to tracks, not presentations. A specific instance of a session,
e.g., one of several concurrent transmissions of the stream in bits per second.
It same content, is set to 0 if non-realtime.

Last Modification Time
Specifies
indicated by the last time Session header field (Section 11.24) where needed.

For example, the object was modified. The specified
time is seconds since Jan 01 1970(UTC).

Reserved
Reserved for future use.

Length
Specifies RTSP URL

  rtsp://media.content.com:554/twister/audiotrack

identifies the stream length in miliseconds. It is 0 if audio track within the object
is live or if it is non-realtime.

Max Packet Size
Specifies presentation ``twister'', which can
be controlled via RTSP requests issued over a TCP connection to port 554 of
host media.content.com.

     This does not imply a standard way to reference tracks in URLs.
     The session description defines the maximum packet size hierarchical relationships in bytes that
     the server
supports for presentation and the stream.

          Flags
             x: Unicast available
             L: Live : if set, URLs for the stream is live individual tracks. A
     session description may name a track 'a.mov' and there is no
                concept the whole
     presentation 'b.mov'.

The path components of position.
             C: Copy : if set, means that the RTSP URL are opaque to the client can save it.
             H: Cached : if set, and do not
imply any particular file system structure for the object is cached on a proxy.
             A: if set, stream can server.

     This decoupling also allows session descriptions to be cached used with
     non-RTSP media control protocols, simply by replacing the client
             U: UDP Okay : if set, scheme
     in the stream URL.

3.3 Conference Identifiers

Conference identifiers are opaque to RTSP and are encoded using standard
URI encoding methods (i.e., LWS is escaped with %). They can contain any
octet value. The conference identifier MUST be sent via a
                unreliable channel.
             M: Stream is available via Multicast, and a
                SET_TRANSPORT message follows providing this
                information

[Note: There has been discussion of providing this
information in a session description that globally unique. For H.323,
the conferenceID value is loaded via
HTTP or some other mechanism prior to the be used.

  conference-id = 1*OCTET  ; LWS must be URL-escaped

     Conference identifiers are used to allow to allow RTSP connection
being established.  See "Metafiles/Session Descriptions" in
http://www.prognet.com/prognet/rt/openissues.html]

SET_TRANSPORT

This message is sent sessions
     to set obtain parameters from multimedia conferences the delivery mechanism for a stream.
The client uses media server
     is participating in. These conferences are created by protocols
     outside the scope of this message to request specification, e.g., H.323 [15] or SIP
     [10]. Instead of the RTSP client explicitly providing transport used
     information, for example, it asks the data transfer.

The media server can use this message to inform use the client about multicast
availability (this is
     values in the conference description instead. If the conference
     participant inviting the media server would only instance supply a
     conference identifier which is unique for that inviting party,
     the media server sends this
message).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     tag (SET_TRANSPORT)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|                              |            ChannelID         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) could add an internal identifier            |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
/                   Transport specific fields                   /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C flag : This flag specifies for that party,
     e.g., its Internet address. However, this would prevent that the type
     conference participant and the initiator of header/framing.

     C =  0  :  Standard RTP header
     C =  1  :  Compressed/Extensible RTP header

SSRC: 32 bits

Identifies the synchronization source RTSP commands are
     two different entities.

3.4 Relative Timestamps

A relative time-stamp expresses time relative to be associated with the
data. This can be used for de-multiplexing by the client start of data
received on the same port.

Channel ID

Transport channel  Fixed RTP header   Compressed RTP header  Channel ID

Unicast UDP          Yes                     Yes                0

Multicast UDP        Yes                     Yes                1

SCP                  Yes                     Yes                2

SCP - compressed     Yes                     Yes                3

Note : clip.
Relative timestamps are expressed as SMPTE time codes for frame-level
access accuracy. The client may not send a channel ID of 1. This is
sent by the server only.

Transport Spcific Fields

Channel ID 0:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|                             port                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Port
Specifies the port number on which the stream should be sent.

Channel ID 2,3 :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|                session ID                     |   (reserved)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Session ID
Specifies time code has the SCP session ID that should be associated format hours:minutes:seconds.frames,
with this
stream.

Channel ID 1

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|                             port                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            address                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Port
Specifies the port number on which origin at the stream is sent.

Address
Specifies start of the multicast group address where clip. For NTSC, the data frame rate is
available.

[Note: There 29.97
frames per second. This is some debate over the best way to address
RTP header compression in handled by dropping the "Compressed RTP section" first frame index of
every minute, except every tenth minute. If the "RTSP Open Issues" document.
(see http://www.prognet.com/prognet/rt/openissues.html)]

[Note: There has also been debate about what level of RTP
support to provide.  It has been suggested that a server
should frame value is zero, it may
be able to stream directly into an RTP based
conference which may contain clients that are not
necessarily RTSP-aware, so long omitted.

  smpte-range = "smpte" "=" smpte-time "-" [ smpte-time ]
  smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ "." 1*2DIGIT ]

Examples:

  10:12:33.40
  10:7:33
  10:7:0

3.5 Absolute Time

Absolute time is expressed as the requesting
conference client provides control connection proxying.
See the "RTSP Open Issues" document section titled "Joining
Into Existing Conferences"
(http://www.prognet.com/prognet/rt/openissues.html)]

SET_SPEED

This advisory message sets the speed ISO 8601 timestamps. It is always expressed
as UTC (GMT).

  utc-range = "clock" "=" utc-time "-" [ utc-time ]
  utc-time = utc-date "T" utc-time "Z"
  utc-date = 8DIGIT ; < YYYYMMDD >
  utc-time = 6DIGIT ; < HHMMSS >

Example for November 8, 1996 at which 14h37 and 20 seconds UTC:

  19961108T143720Z

4 RTSP Message

RTSP is a text-based protocol and uses the server delivers
data ISO 10646 character set in UTF-8
encoding (RFC 2044). Lines are terminated by CRLF, but receivers should be
prepared to the client, contingent on the server's ability also interpret CR and desire LF by themselves as line terminators.

     Text-based protocols make it easier to serve the file at add optional parameters in
     a self-describing manner. Since the given speed. Implementation by number of parameters and the
server
     frequency of commands is optional. The default low, processing efficiency is the bit rate not a
     concern. Text-based protocols, if done carefully, also allow easy
     implementation of the stream.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         tag(SET_SPEED )                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         (reserved)                          |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            speed                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Speed
Send speed research prototypes in scripting languages such
     as a ratio. Tcl, Visual Basic and Perl.

     The speed 10646 character set avoids tricky character set switching,
     but is relative invisible to the normal
speed for the stream, application as expressed long as a ratio of speed
divided by 65536 (i.e. 2^16). For example, speed is 65536
for real-time delivery, 32768 (2^15) for half-speed
delivery, and 131072 (2^17) for double-speed delivery.  A
speed of zero US-ASCII is invalid.

F
If F being
     used. This is set, sends also the data as fast as possible. This feature
only works on encoding used for RTCP. ISO 8859-1
     translates directly into Unicode, with a TCP data connection.

PLAY_RANGE

This message tells the server to start sending data via high-order octet of
     zero. ISO 8859-1 characters with the
previously most-significant bit set transport mechanism. The two fields, From and To,
specify the range in milliseconds. If are
     represented as 1100001x 10xxxxxx.

RTSP messages can be carried over any lower-layer transport protocol that
is 8-bit clean.

Requests contain methods, the object the "To" field method is zero,
it signifies the end of operating upon and
parameters to further describe the stream. If method. Methods are idempotent, unless
otherwise noted. Methods are also designed to require little or no state
maintenance at the "To" field media server.

4.1 Message Types

See [H4.1]

4.2 Message Headers

See [H4.2]

4.3 Message Body

See [H4.3]

4.4 Message Length

When a message-body is non-
zero, it should be greater than included with a message, the value specified in length of that body is
determined by one of the "From" field.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                         tag (PLAY_RANGE)                      |
+-------------------------------+-------------------------------+
|                          From (in ms)                         |
+-------------------------------+-------------------------------+
|                           To following (in ms)                          |
+-------------------------------+-------------------------------+

STREAM_SYNC

This order of precedence):

  1. Any response message which MUST NOT include a message-body (such as
     the 1xx, 204, and 304 responses) is sent always terminated by the server to first
     empty line after the client header fields, regardless of the entity-header
     fields present in response to the PLAY_RANGE message. It informs
  2. If a Content-Length header field (section 11.10) is present, its value
     in bytes represents the client length of the first
expected sequence number, and in case message-body. If this header
     field is not present, a value of some delivery types, zero is assumed.
  3. By the
first expected timestamp.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                         tag (STREAM_SYNC)                     |
+-------------------------------+-------------------------------+
|       Sequence Number         |           Reserved            |
+-------------------------------+-------------------------------+
|                         Start Time                            |
+---------------------------------------------------------------+

Sequence Number
Specifies where server closing the new data starts. This number should be far
enough away from connection. (Closing the last sequence number sent so that old
packets can connection cannot
     be detected and rejected.

Start Time
Specifies the offset (in milliseconds) relative used to indicate the origin end of a request body, since that would leave
     no possibility for the first packet server to send back a response.)

Note that will RTSP does not (at present) support the ``chunked'' transfer
coding and requires the presence of the Content-Length header field.

     Given the moderate length of session descriptions returned, the
     server should always be sent.

SET_BLOCK_SIZE

This able to determine its length, even if it
     is an advisory generated dynamically, making the chunked transfer encoding
     unnecessary. Even though Content-Length must be present if there
     is any entity body, the rules ensure reasonable behavior even if
     the length is not given explicitly.

5 Request

A request message sent from the a client to the a server
setting or vice versa includes, within
the transport packet size. The server truncates it first line of that message, the method to be applied to the
closest multiple resource,
the identifier of the minimum media-specific block size or
overrides it with resource, and the media specific size if necessary.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                       tag (SET_BLOCKSIZE)                     |
+-------------------------------+-------------------------------+
|                          Block Size protocol version in use.

  Request = Request-line CRLF
            *request-header
            CRLF
            [ message-body ]

  Request-Line = Method SP Request-URI SP RTSP-Version SP seq-no CRLF

  Method = "GET"             ; Section
         | "SETUP"           ; Section
         | "PLAY"            ; Section
         | "PAUSE"           ; Section
         | "CLOSE"           ; Section
         | "RECORD"          ; Section
         | "REDIRECT"        ; Section
         | "HELLO"           ; Section
         | "SESSION"         ; Section
         | "BYE"             ; Section
         | "SET_PARAMETER"   ; Section
         | "GET_PARAMETER"   ; Section
         |
+-------------------------------+-------------------------------+

Block Size
Specifies extension-method

  extendion-method = token

  Request-URI = absolute_URI

  RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT

  seq-no = 1*DIGIT

Note that in contrast to HTTP/1.1, RTSP requests always contain the size of
absolute URL (that is, including the block in bytes.

STOP
This messages tells scheme, host and port) rather than
just the server to stop sending. This absolute path.

6 Response

[H6] applies except that HTTP-Version is replaced by RTSP-Version. Also,
RTSP defines additional status codes and does not define some HTTP codes.
The valid response codes and the methods they can be used for
`pause' operation, with are defined
in the table 1 and 2.

After receiving and interpreting a request message, the server recipient responds
with an RTSP response message.

  Response = Status-Line             ; Section
             *( general-header       ; Section
              | response-header      ; Section
              | entity-header )      ; Section
             CRLF
             [ message-body ]        ; Section

6.1 Status-Line

The first line of a Response message is to keep track the Status-Line, consisting of the stream
position in order to `resume' play when
protocol version followed by a resume command is given.

   0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                           tag (STOP)                          |
+-------------------------------+-------------------------------+

RESUME
This message tells numeric status code, the server to resume sending from sequence number of
the position
it was stopped at with corresponding request and the STOP message. If no STOP message was
sent prior to RESUME, textual phrase associated with the messages status
code, with each element separated by SP characters. No CR or LF is ignored.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                           tag (RESUME)                        |
+-------------------------------+-------------------------------+

SEND_REPORT

This message allowed
except in the final CRLF sequence. Note that the addition of a

  Status-Line = RTSP-Version SP Status-Code SP seq-no SP Reason-Phrase CRLF

6.1.1 Status Code and Reason Phrase

The Status-Code element is sent by a 3-digit integer result code of the server attempt to
understand and satisfy the client requesting
statistics on data reception. At request. These codes are fully defined in
section10. The Reason-Phrase is intended to give a minimum, short textual
description of the Status-Code. The Status-Code is intended for use by
automata and the Reason-Phrase is intended for the human user. The client
is not required to reply to examine or display the message Reason-Phrase.

The first digit of type 1 (PING) indicating that
it is receiving data.

    0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 the Status-Code defines the class of response. The last
two digits do not have any categorization role. There are 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                         tag (SEND_REPORT)                     |
+-------------------------------+-------------------------------+
|                           Report Type                         |
+-------------------------------+-------------------------------+

Report Type:
               1 values for the
first digit:

   * 1xx: Informational - PING,
               2 Request received, continuing process
   * 2xx: Success - Text Message
               3 The action was successfully received, understood, and
     accepted
   * 3xx: Redirection - Reception Report

REPORT
Sent by the client Further action must be taken in order to complete
     the server in response request
   * 4xx: Client Error - The request contains bad syntax or cannot be
     fulfilled
   * 5xx: Server Error - The server failed to fulfill an apparently valid
     request

The individual values of the SEND_REPORT
message. or otherwise.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+ numeric status codes defined for RTSP/1.0, and
an example set of corresponding Reason-Phrase's, are presented below. The
reason phrases listed here are only recommended - they may be replaced by
local equivalents without affecting the protocol. Note that RTSP adopts
most HTTP/1.1 status codes and adds RTSP-specific status codes in the
starting at 450 to avoid conflicts with newly defined HTTP status codes.

   Status-Code    = "100"   ; Continue
                  | "200"   ; OK
                  | "201"   ; Created
                  | "202"   ; Accepted
                  | "203"   ; Non-Authoritative Information
                  | "204"   ; No Content
                  | "205"   ; Reset Content
                  | "206"   ; Partial Content
                  | "300"   ; Multiple Choices
                  | "301"   ; Moved Permanently
                  | "302"   ; Moved Temporarily
                  | "303"   ; See Other
                  | "304"   ; Not Modified
                  | "305"   ; Use Proxy
                  | "400"   ; Bad Request
                  | "401"   ; Unauthorized
                  | "402"   ; Payment Required
                  | "403"   ; Forbidden
                  | "404"   ; Not Found
                  | "405"   ; Method Not Allowed
                  | "406"   ; Not Acceptable
                  | "407"   ; Proxy Authentication Required
                  |                           tag (REPORT) "408"   ; Request Time-out
                  | "409"   ; Conflict
                  | "410"   ; Gone
                  | "411"   ; Length Required
                  |
+-------------------------------+-------------------------------+ "412"   ; Precondition Failed
                  |                           Report "413"   ; Request Entity Too Large
                  | "414"   ; Request-URI Too Large
                  | "415"   ; Unsupported Media Type
                  |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ "451"   ; Parameter Not Understood}
                  |               Report Specific Fields "452"   ; Conference Not Found}
                  |
+-------------------------------+-------------------------------+

Report Type:
               1 - PING
               2 - Text Message,
               3 - Reception Report

PING Report (1) Report Specific Fields (NONE, just respond with
                Report type 1)
Text Message (2) Report Specific Fields

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ "453"   ; Not Enough Bandwidth}
                  |        Text String (Null Terminated)                          |
+-------------------------------+-------------------------------+
                Text String (Null terminated).
Reception Report (3) - Report specific fields

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "45x"   ; Session Not Found}
                  | "45x"   ; Method Not Valid in This State}
                  |            Packets Received "45x"   ; Header Field Not Valid for Resource}
                  | "45x"   ; Invalid Range}
                  | "45x"   ; Parameter Is Read-Only}
                  |         Packets Lost "500"   ; Internal Server Error
                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "501"   ; Not Implemented
                  |            Lagging "502"   ; Bad Gateway
                  | "503"   ; Service Unavailable
                  | "504"   ; Gateway Time-out
                  |         Buffer occupancy "505"   ; HTTP Version not supported
                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Packets Received
Specifies extension-code
   extension-code = 3DIGIT

   Reason-Phrase  = *<TEXT, excluding CR, LF>

RTSP status codes are extensible. RTSP applications are not required to
understand the number meaning of packets received since last report

Packets Lost
Specifies the number of packets lost since the last report.

Lagging
Specifies that the buffer level all registered status codes, though such
understanding is below (1), or above the
desired level (0).

Buffer occupancy

Specifies obviously desirable. However, applications MUST understand
the number class of milliseconds below or above the desired
level.

ERROR

This message is sent any status code, as indicated by the server first digit, and treat
any unrecognized response as being equivalent to the client in case x00 status code of
that class, with the exception that an
abnormal condition. It includes a numeric error code which is
defined later in this document and unrecognized response MUST NOT be
cached. For example, if an optional null-terminated
error string.

Error unrecognized status code of 431 is sent received by
the server to report an error to client, it can safely assume that there was something wrong with its
request and treat the client.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                           tag (ERROR)                         |
+-------------------------------+-------------------------------+
|F|                          error code                         |
+-------------------------------+-------------------------------+
|                                                               |
/                   Error String (null-terminated)              /
|                                                               |
+-------------------------------+-------------------------------+

F:(one bit) Fatal Error Flag
Is used response as if it had received a 400 status code. In
such cases, user agents SHOULD present to tell the client it must terminate user the session.

error codes: entity returned with
the response, since that entity is likely to include human-readable
information which will explain the unusual status.

 Code reason                         HELLO GET  SETUP  PLAY  RECORD PAUSE
 100  Continue                       x     x    x      x     x      x
 200 - Success  OK                             x     x    x      x     x      x
 300  Multiple Choices               x     x    x      x     x
 301  Moved Permanently              x     x    x      x     x
 302  Moved Temporarily              x     x    x      x     x
 303  See Other                      x     x    x      x     x
 304  Not Modified                   x     x    x      x     x
 305  Use Proxy                      x     x    x      x     x
 400 - FETCH failure; no such object exists  Bad Request                    x     x    x      x     x      x
 401 - FETCH failure; fetch refused  Unauthorized                   x     x    x      x     x      x
 402 - SEND_RANGE out of bounds  Payment Required               x     x    x      x     x      x
 403 - Incompatible protocol version  Forbidden                      x     x    x      x     x
 404 - SET_TRANSPORT failure; bad port specified  Not Found                      x     x    x      x     x
 405 - Feed gone - live feed closed  Method Not Allowed             x     x    x      x     x      x
 406 - Can't do that on non-live feed  Not Acceptable                 x     x    x      x     x
 407 - Request not supported  Proxy Authentication Required  x     x    x      x     x      x
 408 -  Request refused due to bandwidth mismatch
                     (e.g. Insufficient Client Bandwidth) Timeout                x     x    x      x     x      x
 409  Conflict
 410  Gone                           x     x    x      x     x      x
 411  Length Required                x     x    x
 412  Precondition Failed            x     x
 413  Request Entity Too Large       x     x
 414  Request-URI Too Long           x     x    x      x     x      x
 415  Unsupported Media Type         x     x
 45x  Only Valid for Stream          x     x    x
 45x  Invalid parameter
 45x  Not Enough Bandwidth                      x
 45x  Illegal Conference Identifier
 45x  Illegal Session Identifier                x      x     x      x
 45x  Parameter Is Read-Only
 45x  Header Field Not Valid
 500 - Unspecified server-side problem
               501 -  Internal Server running low on resources Error          x     x    x      x     x      x
 501  Not Implemented                x     x    x      x     x      x
 502  Bad Gateway                    x     x    x      x     x      x
 503  Service Unavailable            x     x    x      x     x      x
 504  Gateway Timeout                x     x    x      x     x      x
 505  RTSP Version Not Supported     x     x    x      x     x      x

Table 1: Status codes and cannot
                     satisfy request

UDP_RESEND

This messages is sent by the client to request retransmission
packets of specific sequence numbers. their usage with RTSP methods
 Code reason                 CLOSE  REDIRECT  GET_PARAMETER SET_PARAMETER
 100  Continue               x      x         x             x
 200  OK                     x      x         x             x
 300  Multiple Choices              x         x             x
 301  Moved Permanently      x      x         x             x
 302  Moved Temporarily      x      x         x             x
 303  See Other              x      x         x             x
 304  Not Modified           x      x         x             x
 305  Use Proxy              x      x         x             x
 400  Bad Request            x      x         x             x
 401  Unauthorized                  x         x             x
 402  Payment Required              x         x             x
 403  Forbidden              x      x         x             x
 404  Not Found              x      x         x             x
 405  Method Not Allowed     x      x         x             x
 406  Not Acceptable         x      x         x             x

 407  Proxy Authentication   x      x         x             x
      Required
 408  Request Timeout        x      x         x             x
 409  Conflict                                x             x
 410  Gone                                    x             x
 411  Length Required                         x             x
 412  Precondition Failed                     x             x

 413  Request Entity Too     x      x         x             x
      Large
 414  Request-URI Too Long   x      x         x             x
 415  Unsupported Media Type
 45x  Only Valid for Stream
 45x  Invalid parameter
 45x  Not Enough Bandwidth

 45x  Illegal Conference
      Identifier

 45x  Illegal Session        x      x
      Identifier
 45x  Parameter Is Read-Only                                x
 45x  Header Field Not Valid
 500  Internal Server Error  x      x         x             x
 501  Not Implemented        x      x         x             x
 502  Bad Gateway            x      x         x             x
 503  Service Unavailable    x      x         x             x
 504  Gateway Timeout        x      x         x             x

 505  RTSP Version Not       x      x         x             x
      Supported

Table 2: Status codes and their usage with RTSP methods

6.1.2 Response Header Fields

The service of response-header fields allow the request
at the server end is optional.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
|                        tag (UDP_RESEND)                       |
+-------------------------------+-------------------------------+
|       Sequence Number         |         Number of Packets     |
+-------------------------------+-------------------------------+

Sequence Number:
Specifies the first packet that needs recipient to be resent.

Number of Packets:
Specifies pass additional
information about the number of packets that need to response which cannot be resent, beginning
with placed in the above sequence number.

3.3 CUSTOM MESSAGES/EVENTS Status-Line.
These messages are intended to provide a general notification
system from header fields give information about the server and about further
access to the client or from the client to resource identified by the
server. The message could Request-URI.

  response-header = Location              ; Section
                    | Proxy-Authenticate  ; Section
                    | Public              ; Section
                    | Retry-After         ; Section
                    | Server              ; Section
                    | Vary                ; Section
                    | WWW-Authenticate    ; Section

Response-header field names can be sent on extended reliably only in combination
with a change in the control protocol version. However, new or object
session. An example of using the custom message is when the
server announces experimental header
fields MAY be given the availability semantics of a new stream, or drives response-header fields if all parties
in the
client's web browser communication recognize them to a particular location.

The message includes payload type and payload. Currently, defined
payload types be response-header fields.
Unrecognized header fields are NewURL(1) treated as entity-header fields.

7 Entity

Request and GotoURL(2). Implementation of
this custom messaging system is optional for both client Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers.

In this section, both sender and recipient refer to either the client or
the server, depending on who sends and vendor specific payload types could who receives the entity.

7.1 Entity Header Fields

Entity-header fields define optional metainformation about the entity-body
or, if no body is present, about the resource identified by the request.

  entity-header  = Allow                    ; Section 14.7
                   | Content-Encoding         ; Section 14.12
                   | Content-Language         ; Section 14.13
                   | Content-Length           ; Section 14.14
                   | Content-Type             ; Section 14.18
                   | Expires                  ; Section 14.21
                   | Last-Modified            ; Section 14.29
                   | extension-header

          extension-header = message-header

The extension-header mechanism allows additional entity-header fields to be added as
necessary.

EVENT_NOTIFY

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
defined without changing the protocol, but these fields cannot be assumed
to be recognizable by the recipient. Unrecognized header fields SHOULD be
ignored by the recipient and forwarded by proxies.

7.2 Entity Body

See [H7.2]

8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        tag(EVENT_NOTIFY)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Payload Type                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                            Payload                            /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Payload Type
Specifies Connections

RTSP requests can be transmitted in several different ways:

   * persistent transport connections used for several request-response
     transactions;
   * one connection per request/response transaction;
   * connectionless mode.

The type of the currently transport connection is defined payload types. For
example, NewURL(1) and GotoURL(2).

Payload by the RTSP URI (Section 3.2).
For the previous two payload types, specifies scheme ``rtsp'', a persistent connection is assumed, while the URL.

3.4 MEDIA SPECIFIC OPTIONS AND EXTENSION MECHANISM

RTSP provides an extensible way
scheme ``rtspu'' calls for RTSP requests to be send without setting up a
connection.

Unlike HTTP, RTSP allows the client media server to query and set
media-specific parameters and send requests to set media-specific parameters
for the stream. This media
client. However, this is done via only supported for persistent connections, as the GET_PARAM and PARAM_REPLY
messages. The GET_PARAM message includes a request ID, family
identifier and a parameter identifier. The PARAM_REPLY mes-
sage includes
media server otherwise has no reliable way of reaching the corresponding request ID, and a variable length
reply data payload.

GET_PARAM

  0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      tag (GET_PARAM)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          REQUEST_ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         FAMILY_ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        PARAMETER_ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

REQUEST_ID
Is a 32 bit number used to reference client. Also,
this request, must be non-
zero.

FAMILY_ID
Currently, RTSP_Audio (Family 1) is defined in Appendix C.

PARAMETER_ID
Specified the parameter ID within the family. These only way that requests from media server to client are defined likely
to traverse firewalls.

8.1 Pipelining

A client that supports persistent connections or connectionless mode MAY
``pipeline'' its requests (i.e., send multiple requests without waiting for the in Appendix C.

PARAM_REPLY

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      tag(PARAM_REPLY)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          REQUEST_ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         FAMILY_ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        PARAMETER_ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         DATA_TYPE                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                            DATA                               /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For a list of currently defined family and parameter identifiers,
see Appendix C. An example of use of these messages is available
each response). A server MUST send its responses to those requests in the next section. Data types are String(0), Integer(1),
same order that the requests were received.

8.2 Reliability and
Opaque data(2).

This message can be sent Acknowledgements

Requests are acknowledged by the server receiver unless they are sent to a
multicast group. If there is no acknowledgement, the client, even if sender may resend the
client has not sent
same message after a request. timeout of one round-trip time (RTT). The client must be prepared to
handle this. In this case, the REQUEST_ID is 0x0.

REQUEST_ID
Is a 32 bit number used to reference this request, must be non-
zero.

FAMILY_ID
Currently, RTSP_Audio (Family 1) round-trip
time is defined estimated as in Appendix C.

PARAMETER_ID

Specified TCP (RFC TBD), with an initial round-trip value of
500 ms. An implementation MAY cache the parameter ID within last RTT measurement as the family. These are defined initial
value for the in Appendix C.

PARAM_REFUSE future connections. If the server does not support the requested parameter or family,
it sends a ParamRefuse, whose format reliable transport protocol is as below:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     tag(PARAM_REFUSE)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          REQUEST_ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         FAMILY_ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        PARAMETER_ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         ERROR_CODE                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

REQUEST_ID
Is a 32 bit number used to reference this request, must
carry RTSP, the timeout value MAY be non-
zero.

FAMILY_ID
Currently, RTSP_Audio (FAMILY_ID1) is defined set to an arbitrarily large value.

     This can greatly increase responsiveness for proxies operating in Appendix C.

PARAMETER_ID
Specified the parameter ID within the family. Currently, the
RTSP_Audio
     local-area networks with small RTTs. The mechanism is defined in Appendix C.

ERROR_CODE: As defined earlier.

SET_PARAM

Using the same principle as GET_PARAM, a media-specific option
for
     such that the stream can client implementation does not have be set using the SET_PARAM message. Examples aware of an option include encryption, custom encoding or quality
levels. The server replies with
     whether a SET_PARAM_REPLY reliable or
PARAM_REFUSE.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     tag (SET_PARAM)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          REQUEST_ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         FAMILY_ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        PARAMETER_ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                            DATA                               /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

REQUEST_ID
Is unreliable transport protocol is being
     used. It is probably a 32 bit number used bad idea to reference this request, must be non-
zero.

FAMILY_ID
Currently, RTSP_Audio (Family 1) is defined in Appendix C.

PARAMETER_ID
Specified the parameter ID within the family. These are defined
for the in Appendix C.

DATA
Specifies have two reliability
     mechanisms on top of each other, although the payload specific RTSP RTT estimate
     is likely to be larger than the family and parameters.

4.0 EXAMPLES/APPLICATION NOTE

Example of use of GetParam to TCP estimate.

Each request and play an audio file:

CLIENT                                SERVER

CONTROL_SCP: HELLO--------------------------->

<---------------------------CONTROL_SCP:HELLO

<--------------------------- CONTROL_SCP:ID

(OPTIONAL) CONTROL_SCP:ID_RESP--------------------->

STREAM_SCP_0: FETCH----------------------------->

STREAM_SCP_0: GETPARAM-------------------------->

STREAM_SCP_0: GETPARAM-------------------------->

<-------------------------  STREAM_SCP_0:STREAM_HEADER

<-------------------------  STREAM_SCP_0:PARAM_REPLY

<-------------------------  STREAM_SCP_0:PARAM_REPLY

STREAM_SCP_0: SETPARAM(eg.encryption) ---------------->

<--------------------------  STREAM_SCP_0:PARAM_REPLY

STREAM_SCP_0: SET_TRANSPORT(RTP)---------------->

STREAM_SCP_0: PLAY_RANGE(a,b)------------------->

<--------------------------- STREAM_SCP_0:STREAM_SYNC

<--------------------------- Data on UDP channel

Example carries a sequence number, which is incremented by one for
each request transmitted. If a request is repeated because of use lack of custom message:

CLIENT                                            SERVER

CONTROL_SCP: HELLO---------------------------->

<----------------------------CONTROL_SCP:HELLO

STREAM_SCP_0: FETCH ------------------->

<--------------------------  STREAM_SCP_0:STREAM_HEADER

STREAM_OBJECT_SCP_0: SET_TRANSPORT(RTP)-------->

STREAM_OBJECT_SCP_0: PLAY_RANGE(a,b)----------------->

<--------------------------- STREAM_SCP_0:STREAMSYNC

<--------------------------- Data on UDP channel

<--------------------------- CONTROL_SCP: EVENT_NOTIFY(NewURL)

STREAM_OBJECT_SCP_1: FETCH--------------------->

<-------------------------  STREAM_SCP_1:STREAM_HEADER

STREAM_SCP_1: SET_TRANSPORT(RTP)---------------->

STREAM_SCP_1: SEEK(a,b)------------------------->

<--------------------------------- STREAM_SCP_1:STREAM_SYNC

<------------------------------- Data on UDP channel

5.0 REFERENCES:

[1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP:
        A Transport Protocol
acknowledgement, the sequence number is incremented.

     This avoids ambiguities when computing round-trip time estimates.

[TBD: An initial sequence number negotiation needs to be added for real-time applications." RFC 1889

[2] Simon Spero, Session Control Protocol(SCP).

[3] J. Postel, J. Reynolds, "Telnet Protocol Spefication.", RFC 854

6.0 APPENDIXES

6.1 APPENDIX A - Data packets

[Note: UDP;
otherwise, a new stream connection may see "Compartmentalize the Protocol" a request be acknowledged by a
delayed response from an earlier ``connection''. This handshake can be
avoided with a sequence number containing a timestamp of sufficiently high
resolution.]

The reliability mechanism described here does not protect against
reordering. This may cause problems in some instances. For example, a CLOSE
followed by a PLAY has quite a different effect than the "RTSP
Open Issues" document reverse.
Similarly, if a PLAY request arrives before all parameters are set due to
reordering, the media server would have to issue an error indication. Since
sequence numbers for discussion of retransmissions are incremented (to allow easy RTT
estimation), the possible split
of this appendix into receiver cannot just ignore out-of-order packets. [TBD:
This problem could be fixed by including both a separate document
(http://www.prognet.com/prognet/rt/openissues.html)]

The following are sequence number that stays
the types of data packet formats.

RTP: same for retransmissions and a timestamp for RTT estimation.]

Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
support UDP. The format of default port for the UDP packet is a standard RTP packet, as
per RFC 1889. This RTSP server is a description 554 for both UDP and
TCP.

A number of how RTSP packets destined for the same control end point may be
packed into a single lower-layer PDU or encapsulated into a TCP stream.
RTSP data MAY be interleaved with RTP and RTCP packets. Unlike HTTP, an
RTSP method header MUST contain a Content-Length whenever that method
contains a payload. Otherwise, an RTSP packet is used terminated with an empty
line immediately following the method header.

9 Method Definitions

The method token indicates the method to be performed on the resource
identified by RTSP. Complete generalized descriptions of these fields can the Request-URI. The method is case-sensitive. New methods
may be
found defined in RFC 1889.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first twelve octets are present in every RTP packet, while the list of CSRC identifiers usually will future. Method names may not start with a $ character
(decimal 24) and must be present (though
may a token.

 method        direction   requirement
 GET           C->S        recommended
 SETUP         C->S        recommended
 PLAY          C->S        required
 PAUSE         C->S        recommended
 CLOSE         C->S        required
 REDIRECT      S->C        optional
 SESSION       S->C        optional
 RECORD        C->S        optional
 BYE           C->S        required?
 SET_PARAMETER C->S, S->C  optional
 GET_PARAMETER C->S, S->C  optional

Table 3: Overview of RTSP methods

     HS: PAUSE is recommend, but not required in that a fully
     functional server can be used when broadcasting an RTP conferencing session, built that does not support this method,
     for example, for live feeds. Similarly, SETUP is not needed for
instance). a
     server that only handles multicast events with transport
     parameters set outside of RTSP. GET and BYE are controversial.

9.1 HELLO

RTSP sessions MAY be initiated by a HELLO message. The fields have request URI is "*"
to indicate that the following meaning:

Version (V): 2 bits
This field identifies request pertains to the version of RTP. session itself. The version used by
this specification is two (2).

Padding (P): 1 bit
If primary
use of the padding bit HELLO message is set, the packet contains one or more
additional padding octets at to verify the end which are not part identity of the
payload. The last octet of sender to the padding contains a count of how
many padding octets should
receiver; both sides must authorize one another to enable full access to
server resources. Unauthorized clients may be ignored.

Extension (X): 1 bit
Not used. Set disconnected or restricted to zero for RTP compatibility. CSRC count (CC): 4
bits. The CSRC count contains the number
a subset of CSRC identifiers that
follow the fixed header.

Marker (M): 1 bit server resources.

In RTSP, this designates addition, if the block boundary. This optional Require header is a point at
which a client can start decoding present, option tags within
the stream.

Payload type (PT): 7 bits
Each stream uses a payload type allocated dynamically between 96
and 127, to remain consistent with header indicate features needed by the dynamic mappings in requestor that are not required
at the
audio-video profile (RFC 1890).

Sequence number: 16 bits
The sequence number increments by version level of the protocol.

Example 1:

  C->S:  HELLO * RTSP/1.0 1
         Require: implicit-play, record-feature
         Transport-Require: switch-to-udp-control, gzipped-messages

Note that these are fictional features (though we may want to make them
real one for each RTP data packet
sent, and day).

Example 2 (using RFC2069-style authentication only as an example):

  S->C: HELLO * RTSP/1.0 1
        Authenticate: Digest realm="testrealm@host.com",
          nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
          opaque="5ccc069c403ebaf9f0171e9517f40e41"

Response:

Possible errors: 401, Parameter Not Understood

Examples:

  S->C:  RTSP/1.0 200 1 OK
         Date: 23 Jan 1997 15:35:06 GMT
         Nack-Transport-Require: switch-to-udp-control

Note that these are fictional features (though we may be used by the receiver want to detect packet loss make them
real one day).

Example 2 (using RFC2069-style authentication only as an example):

  C->S: RTSP/1.0 401 1 Unauthorized
        Authorization: Digest username="Mufasa",
            realm="testrealm@host.com",
            nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
            uri="/dir/index.html",
            response="e966c932a9242554e42c8ee200cec7f6",
            opaque="5ccc069c403ebaf9f0171e9517f40e41"
     HS: I consider HELLO superfluous, not fully specified and
to restore packet sequence. The initial value of the sequence
number just
     complicating client and server. It is random (unpredictable) also not clear how this is
     supposed to work when a client connects to make known plaintext attacks
on encryption more difficult, even if the source itself does
not encrypt, because server, since it
     can't know ahead of time whether the packets server will issus a HELLO
     request. So it may flow through connect, issue a translator SETUP, be refused and then
     somehow guess that does.

Timestamp: 32 bits
The timestamp is a tick mark which reflects the sampling instant it's supposed to wait for HELLO.
     Authentication of the first octet in client can be readily achieved by standard
     HTTP-like methods. On either retrieving the RTP data packet. The clock frequency is
dependent on session description
     or the format of data carried as payload.

SSRC: 32 bits
The SSRC field identifies first SETUP, the synchronization source associated server would refuse with 401, supply the data. This identifier
     authentication methods (and nonces) it is chosen willing to accept and
     wait for the request to be re-issued with proper authentication.
     As with standard web browser, a client can cache the intent that no
two synchronization sources within
     authentication message for efficiency.

     Similarly, the same RTSP session will
have client can ask the same SSRC.

CSRC list: 0 server to 15 items, 32 bits each
The CSRC list identifies the contributing sources for authenticate itself
     with the payload
contained in this packet. first request.

     Feature announcement can be done using standard HTTP mechanism,
     with a well-defined registration mechanism for feature names.

     RL: HELLO offers the opportunity to negotiate server features
     prior to actually needing them. A client may wish to poll a
     server for its features without actually causing any action to
     occur, and HELLO offers that opportunity.

9.2 GET

The number of identifiers is given by GET method retrieves a session description from a server. It may use
the CC field. Accept header to specify the session description formats that the
client understands.

If there are more than 15 contributing sources,
only 15 may be identified.

Compressed RTP
[Note: There the media server has previously been some questions as invited to a conference by the
appropriateness of this name, since it is really an
application-level compression
client, the GET request SHOULD contain the Conference header field. If the
GET request contains a conference identifier, the media server MAY locate
the conference description and use the multicast addresses and port numbers
supplied in that relies on RTSP description. The media server SHOULD only offer media
types corresponding to carry
some of the "compressed" information out of band.  We will
probably change this name to reflect its distance from RTP.]

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|v|M|t|s| SSRC  |   sequence number             |timestamp (opt)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...              |
+-+-+-+-+-+-+-+-+

version (v): 1 bit media types currently active within the
conference. If this is 1, the rest of media server has no local reference to this packet is standard RTP, and we can
treat it as such. If conference,
it returns status code 452.

The conference invitation should also contain an indication whether the
media server is 0, expected to receive or generate media, or both. (A VCR-like
device would support both directions.) If the rest invitation does not contain
an indication of the packet is defined
as follows.

marker (M): 1 bit
In RTSP, this designates operations to be performed, the block boundary. This is a point at
which media server should
accept and then reject inappropriate operations.

The server responds with a client can start decoding the stream.

timestamp lower bits compression bit (t): 1 bit
This number specifies the existence of the least-significant two
bytes description of the timestamps. If this bit is not set, requested resource.

Example:

  C->S: GET rtsp://server.example.com/fizzle/foo RTSP/1.0 312
        Accept: application/sdp, application/sdf, application/mheg
        Bandwidth: 4000

  S->C: RTSP/1.0 200 312 OK
        Date: 23 Jan 1997 15:35:06 GMT
        Content-Type: application/sdp
        Content-Length: 376

        v=0
        o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
        s=SDP Seminar
        i=A Seminar on the value session description protocol
        u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
        e=mjh@isi.edu (Mark Handley)
        c=IN IP4 224.2.17.12/127
        t=2873397496 2873404696
        a=recvonly
        m=audio 3456 RTP/AVP 0
        m=video 2232 RTP/AVP 31
        m=whiteboard 32416 UDP WB
        a=orient:portrait

or

  S->C: RTSP/1.0 200 312 OK
        Date: 23 Jan 1997 15:35:06 GMT
        Content-Type: application/x-rtsp-mh
        Content-Length: 2782

        <2782 octets of
these bytes are calculated based some media-specific method
(probably using data containing stream descriptions and
        headers for the sequence number). If this bit requested presentation>

     The authors disagree amongst themselves as to whether having an
     GET method within RTSP is set, the
value of these bytes are given in this packet. appropriate. The upper bits are determined based on the probable value given alternative would be
     that the sequence number. This compression scheme does not work stream header would be done as an HTTP GET, and then
     RTSP would be used for
packets that SETUP, PLAY, etc. RL believes there are spaced out at intervals greater than roughly 64
seconds.

sequence a
     number inclusion bit(s)
This bit of reasons why a GET method is appropriate within RTSP:

        * An RTSP GET is a request for header information, while an
          HTTP GET is a request for compatibility with reliable, sequenced delivery
mechanisms, such as SCP. This should always be set to 1.

SSRC: 4 bits or 36 bits
The SSRC field identifies the synchronization source associated entire file. For instance, an
          RTSP GET on a Quicktime file with the data. This identifier is chosen with name foo.mov would
          mean "please send me the intent header and packetization
          information for foo.mov", whereas an HTTP GET for that no
two synchronization sources within the same RTSP session will
have file
          would mean "please send me foo.mov".
        * Assuming the same SSRC.

This is 4 bits unless set client only has an URL to 15 (1111), in which case a resource, it expands is
          highly desireable to get to 36 bits, and the lower 32 bits are point where the actual SSRC.

sequence number: 16 bits
The sequence number increments by client is
          actually receiving data all over one for each RTP data packet
sent, and may connection. Though this
          would be used by possible if one assumed that one can multiplex RTSP
          and HTTP on the receiver same connection, there is a question of how
          much of a web server would have to detect packet loss and be supported in order to restore packet sequence. The initial value of
          fulfill this simpler requirement.
        * Since the sequence
number RTSP GET contains information such as codec,
          packetization, total size, and whether the clip is random (unpredictable) live or
          stored, it is important to make known-plaintext attacks
on encryption more difficult, even if insure integrity between the source itself does
not encrypt, because
          session description and the packets media it represents. This
          information may flow through a translator be cached by HTTP proxies, but it would be
          needed by caching RTSP proxies.

     RL and AR feel that does.

6.2 APPENDIX B - Session Control Protocol (SCP)

[Note: see "Compartmentalize the Protocol" in the "RTSP
Open Issues" document for discussion of the possible split scope and applicability of this appendix into a separate document
(http://www.prognet.com/prognet/rt/openissues.html)]

[Note: other methods of multiplexing are currently being
discussed.  Simon Spero has a new draft of SCP at
http://sunsite.unc.edu/ses/scp.html.  SMUX, from Jim
Gettys message
     should be limited, and the W3C at http://www.w3.org is therefore, it may be appropriate to come
     up with another candidate.]

This document was originally written by Simon Spero name for this message.

     HS believes that this only works if GET is required. Otherwise,
     the HTTP-
NG project. It client has been slightly editied and clarified.

Several heavily used Internet applications such as FTP, GOPHER,
and HTTP use no way of knowing whether to first send a protocol model GET or
     SETUP. The easy alternative is to have any further descriptive
     information that is necessary encoded in which every transaction
requires the session description.
     Thus, the naming does not matter; the resource description can
     either have a separate TCP connection. Since clients normally issue
multiple requests to name or the same server, this model is quite
inefficient, as it incurs all name if the connection start up costs for
every single request.

SCP is a simple protocol which lets a server and client have
multiple conversations over a can
     distinguish variants based on the requested type, as modern web
     servers can. (A single TCP connection.

Definitions

A session is a virtual stream URL can return different objects depending
     on the content of data carried within the single
TCP connection. Accept fields.) It is independent appears likely that the
     RTSP GET will over time acquire all the functionality of the HTTP
     GET and thus lead to unnecessary duplication. If the description
     is lengthy, the ability to use HTTP caches is likely to
     compensate for any other session within additional latency due to having to open two
     streams. Also, note that relying on HTTP get does not mean that
     this has to be a separate server.

9.3 SETUP

The SETUP request for a URI specifies the
same connection. transport mechanism to be used
for the streamed media. Note that SETUP makes sense only for an individual
media stream, rather than an aggregate. A session identifier is client can issue a unique number which SETUP request
for a stream that is used already playing to specify
which session a particular block of data change transport parameters.

If the optional Require header is associated with.

Session flag names present, option tags within the header
indicate features needed by the requestor that are borrowed from TCP. not required at the
version level of the protocol. The name SYN means
"open" in SCP. Transport-Require header is used to
indicate proxy-sensitive features that MUST be stripped by the proxy to the
server if not supported. Furthermore, any Transport-Require header features
that are not supported by the proxy MUST be negatively acknowledged by the
proxy to the client if not supported.

     HS: In my opinion, the Require header should be replaced by PEP
     since PEP is standards-track, has more functionality and somebody
     already did the work.

The name FIN means "finish" or "close" in SCP. Transport header specifies the transports acceptable to the client for
data transmission; the response will contain the transport selected by the
server.

  C->S: SETUP foo/bar/baz.rm RTSP/1.0 302
        Transport: rtp/udp;port=458

  S->C: RTSP/1.0 200 302 OK
        Date: 23 Jan 1997 15:35:06 GMT
        Transport: cush/udp;port=458

9.4 PLAY

The
name RST means "reset" in SCP. PUSH indicates PLAY method tells the end of server to start sending data via the mechanism
specified in SETUP. A client MUST NOT issue a
segment.

Services

SCP's main service PLAY request until any
outstanding SETUP request have been acknowledged as successful.

A PLAY request without a Range header is dialogue control. legal. It starts playing a stream
from the beginning unless the stream has been paused. If a stream has been
paused via PAUSE, stream delivery resumes at the pause point. If a stream
is playing, such a PLAY request causes no further action and can be used by
the client to test server liveness.

The following example plays the whole session starting at SMPTE time code
0:10:20 until the end of the clip.

  C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 833
        Range: smpte=0:10:20-

For playing back a recording of a live event, it may be desirable to use
clock units:

  C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0 835
        Range: clock=19961108T142300Z-19961108T143520Z
  S->C: RTSP/1.0 200 833 OK
        Date: 23 Jan 1997 15:35:06 GMT

A media server only supporting playback MUST support the smpte format and
MAY support the clock format.

     RL says: We had considered optionally overloading PLAY with SETUP
     information. This would have potentially allowed a case where one
     could implement a minimal RTSP server that only handles the PLAY
     command. However, we decided that supporting that minimal of a
     server was problematic for a couple of reasons:

        * We must be able to negotiate the transport (i.e. have server
          acknowledgment) prior to actually needing to deal with the
          data. We don't want to have a server start spewing packets
          at us before we are ready to deal with them. The server
          acknowledgment with setup information MUST arrive before the
          first packet.
        * We need make sure that we aren't dealing with an allocation
          method every time we are dealing with PLAY. We anticipate
          the potential of dealing with PLAY frequently when a client
          chooses to issue several seeks, and so simplifying this
          message is imperative.

     HS says: PLAY without SETUP is useful and possible, in particular
     if the session description contains all necessary information,
     without options. The client knows whether it needs to configure
     transport parameters or not. For multicast delivery, for example,
     it likely would not have to set additional parameters. I doubt
     that allowing one additional parameter is going to greatly
     complicate or slow down a server.

9.5 PAUSE

The PAUSE request causes the stream delivery to be interrupted (halted)
temporarily. If the request URL names a track, only playback and recording
of that track is halted. If the request URL names a presentation, delivery
of all currently active tracks is halted. After resuming playback or
recording, synchronization of the tracks MUST be maintained. Any server
resources are kept.

Example:

  C->S: PAUSE /fizzle/foo RTSP/1.0 834

  S->C: RTSP/1.0 200 834 OK
        Date: 23 Jan 1997 15:35:06 GMT

9.6 CLOSE

Stop the stream delivery for the given URI, freeing the resources
associated with it. If the URI is the root node for this session, any
session identifier associated with the session is no longer valid. Unless
all transport parameters are defined by the session description, a SETUP
request has to be issued before the session can be played again.

Example:

  C->S: CLOSE /fizzle/foo RTSP/1.0 892

  S->C: RTSP/1.0 200 892 OK

9.7 BYE

Terminate the session.

Example:

  C->S: BYE /movie RTSP/1.0 894

  S->C: RTSP/1.0 200 894 OK
        Date: 23 Jan 1997 15:35:06 GMT

     HS: I believe BYE to be unnecessary since CLOSE already frees
     resources and session descriptor.

9.8 GET_PARAMETER

The requests retrieves the value value of a parameter of a session
component specified in the URI. Multiple parameters can be requested in the
message body using the content type text/rtsp-parameters. Note that
parameters include server and client statistics. [HS: registry of parameter
names for statistics and other purposes, possibly using the HTTP feature
registration mechanism.] A GET_PARAMETER with no entity body may be used to
test client or server liveness (``ping'').

Example:

  S->C: GET_PARAMETER /fizzle/foo RTSP/1.0 431
        Content-Type: text/rtsp-parameters
        Session: 1234
        Content-Length: 15

        packets_received
        jitter

  C->S: RTSP/1.0 200 431 OK
        Content-Length: 46
        Content-Type: text/rtsp-parameters

        packets_received: 10
        jitter: 0.3838

9.9 SET_PARAMETER

This method requests to set the value of a parameter for a session
component specified by the URI.

A request SHOULD only contain a single parameter to allow the client to
determine why a particular request failed. A server MUST allow a parameter
to be set repeatedly to the same value, but it MAY disallow changing
parameter values.

Note: transport parameters for the media stream MUST only be set with the
SETUP command.

     Restricting setting transport parameters to SETUP is for the
     benefit of firewalls.

     The parameters are split in a fine-grained fashion so that there
     can be more meaningful error indications. However, it may make
     sense to allow the setting of several parameters if an atomic
     setting is desirable. Imagine device control where the client
     does not want the camera to pan unless it can also tilt to the
     right angle at the same time.

A SET_PARAMETER request without parameters can be used as a way to detect
client or server liveness.

Example:

  C->S: SET_PARAMETER /fizzle/foo RTSP/1.0 421
        Content-type: text/rtsp-parameters

        fooparam: foostuff
        barparam: barstuff

  S->C: RTSP/1.0 450 421 Invalid Parameter
        Content-Length: 6

        barparam

9.10 REDIRECT

A redirect request informs the client that it must connect to another
server location. It contains the mandatory header Location, which indicates
that the client should issue a GET for that URL. It may contain the
parameter Range, which indicates when the redirection takes effect.

Mandatory header: Location [XXX: add this to table if accepted]

Example: This request redirects traffic for this URI to the new server at
the given play time:

  S->C: REDIRECT /fizzle/foo RTSP/1.0 732
        Location: rtsp://bigserver.com:8001
        Range: clock=19960213T143205Z-

9.11 SESSION

This request is used by a media server to send new media information to the
client. If a new media type is added to a session (e.g., during a live
event), the whole session description should be sent again, rather than
just the additional components.

     This allows the deletion of session components.

Example:

  S->C: SESSION /twister RTSP/1.0 902
        Session: 1234
        Content-Type: application/sdp
        Session Description

9.12 RECORD

This method initiates recording a range of media data according to the
session description. The timestamp reflects start and end time (UTC). If no
time range is given, use the start or end time provided in the session
description. If the session has already started, commence recording
immediately. The Conference header is mandatory.

A media server supporting recording of live events MUST support the clock
range format; the smpte format does not make sense.

In this example, the media server was previously invited to the conference
indicated.

  C->S:  RECORD /meeting/audio.en RTSP/1.0 954
         Session: 1234
         Conference: 128.16.64.19/32492374

9.13 Embedded Binary Data

Binary packets such as RTP data are encapsulated by an ASCII dollar sign
(24 decimal), followed by a one-byte session identifier, followed by the
length of the encapsulated binary data as a binary, two-byte integer in
network byte order. The binary data follows immediately afterwards, without
a CRLF.

Status Codes Definitions

Where applicable, HTTP status [H10] codes are re-used. Status codes that
have the same meaning are not repeated here. See Tables 1 and 2 for a
listing of which status codes may be returned by which request.

10.1 Client Error 4xx

10.1.1 451 Parameter Not Understood

The recipient of the request does not support one or more parameters
contained in the request.

10.1.2 452 Conference Not Found

The conference indicated by a Conference header field is unknown to the
media server.

10.1.3 453 Not Enough Bandwidth

The request was refused since there was insufficient bandwidth. This may,
for example, be the result of a resource reservation failure.

10.1.4 45x Session Not Found

10.1.5 45x Method Not Valid in This State

10.1.6 45x Header Field Not Valid for Resource

The server could not act on a required request header. For example, if PLAY
contains the Range header field, but the stream does not allow seeking.

10.1.7 45x Invalid Range

The Range value given is out of bounds, e.g., beyond the end of the
presentation.

10.1.8 45x Parameter Is Read-Only

The parameter to be set by SET_PARAMETER can only be read, but not
modified.

11 Header Field Definitions

HTTP/1.1 or other, non-standard header fields not listed here currently
have no well-defined meaning and SHOULD be ignored by the recipient.

Tables 4 and 5 summarize the header fields used by RTSP. Type ``R''
designates requests, type ``r'' responses. Fields marked with ``x'' MUST be
implemented by the recipient. If the field content does not apply to the
particular resource, the server MUST return status 45x (Header Field Not
Valid for Resource).

                   type  HELLO  GET  SETUP PLAY  RECORD  PAUSE
 Accept            R            x
 Accept-Encoding   R            x
 Accept-Language   R            x    o     o
 Authorization     R     o      o    o     o     o       o
 Bandwidth         R                 o
 Blocksize         R                 o
 Conference        R            o    o     ?     ?       ?
 Connection        Rr           x    x     x     x       x
 Content-Encoding  Rr           x
 Content-Length    Rr           x
 Content-Type      Rr           x
 Date              Rr    o      o    o     o     o       o
 If-Modified-Since R            o
 Last-Modified     r            o
 Public            r     o      o    o     o     o       o
 Range             R                       x     x
 Referer           R     o      o    o     o     o       o
 Require           R     x      o    x     o     o       o
 Retry-After       r     o      o    o     o     o       o
 Session           Rr                x     x     x       x
 Server            r     o      o    o     o     o       o
 Speed             Rr                      o     o
 Transport         Rr                x
 Transport-Require R     x      o    x     o     o       o
 User-Agent        R     o      o    o     o     o       o
 Via               Rr    o      o    o     o     o       o
 WWW-Authenticate  r     o      o    o     o     o       o

Table 4: Overview of RTSP header fields for GET, SETUP, PLAY, RECORD and
PAUSE
                   CLOSE  REDIRECT  GET_PARAMETER  SET_PARAMETER
 Accept
 Accept-Encoding
 Accept-Language
 Authorization     o      o         o              o
 Bandwidth
 Blocksize
 Conference
 Connection        x      x         x              x
 Content-Encoding  x      x         x              x
 Content-Length    x      x         x              x
 Content-Type      x      x         x              x
 Date              o      o         o              o
 If-Modified-Since
 Last-Modified
 Public            o      o         o              o
 Range
 Referer           o      o         o              o
 Retry-After       o      o         o              o
 Session           x      x         x              x
 Server            o      o         o              o
 Speed
 Transport
 User-Agent        o      o         o              o
 Via               o      o         o              o
 WWW-Authenticate  o      o         o              o

Table 5: Overview of RTSP header fields for PAUSE, CLOSE, GET_PARAMETER and
SET_PARAMETER

11.1 Accept

The Accept request-header field can be used to specify certain session
description content types which are acceptable for the response.

     The ``level'' parameter for session descriptions is properly
     defined as part of the MIME type registration, not here.

See [H14.1] for syntax.

Example of use:

Accept: application/sdf, application/sdp;level=2

11.2 Accept-Encoding

See [H14.3]

11.3 Accept-Language

See [H14.4]. Note that the language specified applies to the session
description, not the media content.

11.4 Allow

The Allow response header field lists the methods supported by the resource
identified by the request-URI. The purpose of this field is to strictly
inform the recipient of valid methods associated with the resource. An
Allow header field must be present in a 405 (Method not allowed) response.

Example of use:

  Allow: SETUP, PLAY, RECORD, SET_PARAMETER

11.5 Authorization

See [H14.8]

11.6 Bandwidth

The Bandwidth request header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured in
bits per second.

  Bandwidth  = "Bandwidth" ":" 1*DIGIT

Example:

  Bandwidth: 4000

11.7 Blocksize

This request header field is sent from the client to the media server
asking the server for a particular media packet size. This packet size does
not include lower-layer headers such as IP, UDP, or RTP. The server is free
to use a blocksize which is lower than the one requested. The server MAY
truncate this packet size to the closest multiple of the minimum
media-specific block size or overrides it with the media specific size if
necessary. The block size is a strictly positive decimal number and
measured in octets. The server only returns an error (416) if the value is
syntactically invalid.

11.8 Conference

This request header field establishes a logical connection between a
conference, established using non-RTSP means, and an RTSP stream.

  Conference = "Conference" ":" conference-id

Example:

  Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr

11.9 Content-Encoding

See [H14.12]

11.10 Content-Length

This field contains the length of the content of the method (i.e. after the
double CRLF following the last header). Unlike HTTP, it MUST be included in
all messages that carry content beyond the header portion of the message.
It is interpreted according to [H14.14].

11.11 Content-Type

See [H14.18]. Note that the content types suitable for RTSP are likely to
be restricted in practice to session descriptions and parameter-value
types.

11.12 Date

See [H14.19].

11.13 If-Modified-Since

See [H14.24]. If the request URL refers to a presentation rather than a
track, the server is to return the presentation if any of the track has
been modified since the time stated in the header field.

11.14 Last-modified

The Last-Modified entity-header field indicates the date and time at which
the origin server believes the variant was last modified. See [H14.29]. If
the request URI refers to an aggregate, the field indicates the last
modification time across all leave nodes of that aggregate.

11.15 Location

See [H14.30].

11.16 Range

This request header field specifies a range of time. The range can be
specified in a number of units. This specification defines the smpte (see
Section 3.4) and clock (see Section 3.5) range units. Within RTSP, byte
ranges [H14.36.1] are not meaningful and MUST NOT be used.

  Range = "Range" ":" 1#ranges-specifier

  ranges-specifier = utc-range | smpte-range

Example:

  Range: clock=19960213T143205Z-

11.17 Require

The Require header is used by clients to query the server about features
that it may or may not support. The server MUST respond to this header by
negatively acknowledging those features which are NOT supported in the
Unsupported header.

     HS: Naming of features - yet another name space. I believe this
     header field to be redundant. PEP should be used instead.

For example

C->S:   SETUP /foo/bar/baz.rm RTSP/1.0 302
        Require: funky-feature
        Funky-Parameter: funkystuff

S->C:   RTSP/1.0 200 506 Option not supported
        Unsupported: funky-feature

C->S:   SETUP /foo/bar/baz.rm RTSP/1.0 303

S->C:   RTSP/1.0 200 303 OK

This is to make sure that the client-server interaction will proceed
optimally when all options are understood by both sides, and only slow down
if options aren't understood (as in the case above). For a well-matched
client-server pair, the interaction proceeds quickly, saving a round-trip
often required by negotiation mechanisms. In addition, it also removes
state ambiguity when the client requires features that the server doesn't
understand.

11.18 Unsupported

See Section 11.17 for a usage example.

     HS: same caveat as for Require applies.

11.19 Nack-Transport-Require

Negative acknowledgement of features not supported by the server. If there
is a proxy on the path between the client and the server, the proxy MUST
insert a message reply with an error message 506 (Feature not supported).

     HS: Same caveat as for Require applies.

11.20 Transport-Require

The Transport-Require header is used to indicate proxy-sensitive features
that MUST be stripped by the proxy to the server if not supported.
Furthermore, any Transport-Require header features that are not supported
by the proxy MUST be negatively acknowledged by the proxy to the client if
not supported.

See Section 11.17 for more details on the mechanics of this message and a
usage example.

     HS: Same caveat as for Require applies.

11.21 Retry-After

See [H14.38].

11.22 Speed

This request header fields parameter requests the server to deliver data to
the client at a particular speed, contingent on the server's ability and
desire to serve the media stream at the given speed. Implementation by the
server is OPTIONAL. The default is the bit rate of the stream.

The parameter value is expressed as a decimal ratio, e.g., a value of 2.0
indicates that data is to be delivered twice as fast as normal. A speed of
zero is invalid. A negative value indicates that the stream is to be played
back in reverse direction.

  speed = "Speed" ":" ["-"]1*DIGIT [ "." *DIGIT ]

Example:

  Speed: 2.5

11.23 Server

See [H14.39]

11.24 Session

This request and response header field identifies a session, started by the
media server in a SETUP or PLAY response and concluded by CLOSE on the
session URL (presentation). The session identifier is chosen by the media
server and has the same syntax as a conference identifier. Once a client
receives a Session identifier, it MUST return it for any request related to
that session.

     HS: This may be redundant with the standards-track HTTP state
     maintenance mechanism [1]. The equivalent way of doing this would
     be for the server to send Set-Cookie: Session="123"; Version=1;
     Path = "/twister" and for the client to return later Cookie:
     Session = "123"; $Version=1; $Path = "/twister". In the response
     to the CLOSE message, the server would simply send Set-Cookie:
     Session="123"; Version=1; Max-Age=0 to get rid of the cookie on
     the client side. Cookies also have a time-out, so that a server
     may limit the lifetime of a session at will. Unlike a web
     browser, a client would not store these states on disk.

11.25 Transport

This request header indicates which transport protocol is to be used and
configures its parameters such as multicast, compression, multicast
time-to-live and destination port for a single stream. It sets those values
not already determined by a session description. In some cases, the session
description contains all necessary information. In those cases, a Transport
header field (and the SETUP request containing it) are not needed.

'Interleaved' implies mixing the media stream with the control stream, in
whatever protocol is being used by the control stream. Currently, the
next-layer protocols RTP is defined. Parameters may be added to each
protocol, separated by a semicolon. For RTP, the boolean parameter
compressed is defined, indicating compressed RTP according to RFC XXXX. For
multicast UDP, the integer parameter ttl defines the time-to-live value to
be used. For UDP and TCP, the parameter port defines the port data is to be
sent to.

The SSRC parameter indicates the RTP SSRC value that should be (request)i
or will be (response) used by the media server. This parameter is only
valid for unicast transmission. It identifies the synchronization source to
be associated with the media stream.

The Transport header MAY also be used to change certain transport
parameters. A server MAY refuse to change parameters of an existing stream.

The server MAY return a Transport response header in the response to
indicate the values actually chosen.

A Transport request header field may contain a list of transport options
acceptable to the client. In that case, the server MUST return a single
option which was actually chosen. The Transport header field makes sense
only for an individual media stream, not a session.

  Transport = "Transport" ":"
              1#transport-protocol/upper-layer *parameter
  transport-protocol = "UDP" | "TCP"
  upper-layer  = "RTP"
  parameters = ";" "multicast" |
               ";" "compressed" |
               ";" "interleaved" |
               ";" "ttl" "=" ttl |
               ";" "port" "=" port |
               ";" "ssrc" "=" ssrc
  ttl        = 1*3(DIGIT)
  port       = 1*5(DIGIT)
  ssrc       = 8*8(HEX)

Example:

  Transport: udp/rtp;compressed;ttl=127;port=3456

11.26 User-Agent

See [H14.42]

11.27 Via

See [H14.44].

11.28 WWW-Authenticate

See [H14.46].

12 Caching

In HTTP, response-request pairs are cached. RTSP differs significantly in
that respect. Typically, responses are not cachable (except maybe for the
GET response), rather it is desirable for the media data (that is typically
delivered outside of RTSP) to be cached. Since the responses for anything
but GET and GET_PARAMETER do not return any data, caching is not an issue
for these requests.

HS: A proxy cache for RTSP would look not much different from an HTTP
cache. To the client, the proxy cache would appear like a regular media
server, to the media server like a client. Just like an HTTP cache has to
store the content type, content language, etc. for the objects it caches, a
media cache has to store the session description. Typically, a cache would
eliminate all transport-references (that is, multicast information) from
the session description, since these are independent of the data delivery
from the cache to the client. Information on the encodings remains the
same. If the cache is able to translate the cached media data, it would
create a new session description with all the encoding possibilities it can
offer.

13 Examples

To emphasize that RTSP is independent of the session description format,
the following examples use a fictional session description language which
is chosen to be sufficiently self-explanatory.

13.1 Media on Demand (Unicast)

Client C requests a movie from media servers A ( audio.content.com) and V
(video.content.com). The media description is stored on a web server W.
This, however, is transparent to the client. The client is only interested
in the last part of the movie. The server requires authentication for this
movie. The audio track can be dynamically switched between between two sets
of encodings. The URL with scheme rtpsu indicates the media servers want to
use UDP for exchanging RTSP messages.

C->W: GET /twister HTTP/1.1
      Host: www.content.com
      Accept: application/sdf; application/sdp

W->C: 200 OK
      Content-Type: application/sdf
      (session
        (all
         (media (t audio) (oneof
            ((e PCMU/8000/1 89 DVI4/8000/1 90) (id lofi))
            ((e DVI4/16000/2 90 DVI4/16000/2 91) (id hifi))
           )
           (language en)
           (id rtspu://audio.content.com/twister/audio.en)
           )
           (media (t video) (e JPEG)
             (id rtspu://video.content.com/twister/video)
           )
         )
       )

C->A: SETUP rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 1
      Transport: rtp/udp;compression;port=3056

A->C: RTSP/1.0 200 1 OK
      Session: 1234

C->V: SETUP rtsp://video.content.com/twister/video RTSP/1.0 1
      Transport: rtp/udp;compression;port=3058

V->C: RTSP/1.0 200 1 OK
      Session: 1235

C->V: PLAY rtsp://video.content.com/twister/video RTSP/1.0 2
      Session: 1235
      Range: smpte 0:10:00-

V->C: RTSP/1.0 200 2 OK

C->A: PLAY rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 2
      Session: 1234
      Range: smpte 0:10:00-

A->C: 200 2 OK

C->A: CLOSE rtsp://audio.content.com/twister/audio.en/lofi RTSP/1.0 3
      Session: 1234

A->C: 200 3 OK

C->V: CLOSE rtsp://video.content.com/twister/video RTSP/1.0 3
      Session: 1235

V->C: 200 3 OK

Even though the audio and video track are on two different servers, may
start at slightly different times and may drift with respect to each other,
the client can synchronize the two using standard RTP methods, in
particular the time scale contained in the RTCP sender reports.

13.2 Live Media Event Using Multicast

The media server M chooses the multicast address and port. Here, we assume
that the web server only contains a pointer to the full description, while
the media server M maintains the full description. During the session, a
new subtitling stream is added.

C->W: GET /concert HTTP/1.1
      Host: www.content.com

W->C: HTTP/1.1 200 OK
      Content-Type: application/sdf

      (session
        (id rtsp://live.content.com/concert)
      )

C->M: GET rtsp://live.content.com/concert RTSP/1.0 1

M->C: RTSP/1.0 200 1 OK
      Content-Type: application/sdf

      (session (all
        (media (t audio) (id music) (a IP4 224.2.0.1) (p 3456))
      ))

C->M: PLAY rtsp://live.content.com/concert/music RTSP/1.0 2
      Range: smpte 1:12:0

M->C: RTSP/1.0 405 2 No positioning possible

M->C: SESSION concert RTSP/1.0
      Content-Type: application/sdf

      (session (all
        (media (t audio) (id music))
        (media (t text) (id lyrics))
      ))

C->M: PLAY rtsp://live.content.com/concert/lyrics RTSP/1.0

Since the session description already contains the necessary address
information, the client does not set the transport address. The attempt to
position the stream fails since this is a live event.

13.3 Playing media into an existing session

A conference participant C wants to have the media server M play back a
demo tape into an existing conference. When retrieving the session
description, C indicates to the media server that the network addresses and
encryption keys are already given by the conference, so they should not be
chosen by the server. The example omits the simple ACK responses.

C->M: GET /demo HTTP/1.1
      Host: www.content.com
      Accept: application/sdf, application/sdp

M->C: HTTP/1.1 200 1 OK
      Content-type: application/sdf

      (session
         (id 548)
         (media (t audio) (id sound)
      )

C->M: SETUP rtsp://server.content.com/demo/548/sound RTSP/1.0 2
      Conference: 218kadjk

13.4 Recording

Conference participant C asks the media server M to record a session. If
the session description contains any alternatives, the server records them
all.

C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 89
      Content-Type: application/sdp

      v=0
      s=Mbone Audio
      i=Discussion of Mbone Engineering Issues

M->C: 415 89 Unsupported Media Type
      Accept: application/sdf

C->M: SESSION rtsp://server.content.com/meeting RTSP/1.0 90
      Content-Type: application/sdf

M->C: 200 90 OK

C->M: RECORD rtsp://server.content.com/meeting RTSP/1.0 91
      Range: clock 19961110T1925-19961110T2015

14 Syntax

The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used
in RFC 2068 (HTTP/1.1).

14.1 Base Syntax

OCTET     = <any 8-bit sequence of data>
CHAR      = <any US-ASCII character (octets 0 - 127)>
UPALPHA   = <any US-ASCII uppercase letter "A".."Z">
LOALPHA   = <any US-ASCII lowercase letter "a".."z">
ALPHA     = UPALPHA | LOALPHA
DIGIT     = <any US-ASCII digit "0".."9">
CTL       = <any US-ASCII control character
             (octets 0 - 31) and DEL (127)>
CR        = <US-ASCII CR, carriage return (13)>
LF        = <US-ASCII LF, linefeed (10)>
SP        = <US-ASCII SP, space (32)>
HT        = <US-ASCII HT, horizontal-tab (9)>
<">       = <US-ASCII double-quote mark (34)>
CRLF      = CR LF
LWS       = [CRLF] 1*( SP | HT )
TEXT      = <any OCTET except CTLs>
tspecials = "(" | ")" | "<" | ">" | "@"
          | "," | ";" | ":" | "\" | <">
          | "/" | "[" | "]" | "?" | "="
          | "{" | "}" | SP | HT
token = 1*<any CHAR except CTLs or tspecials>
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR

message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and consisting
                 of either *TEXT or combinations of token, tspecials,
                 and quoted-string>

14.2 Internet Media Type Syntax

media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-string

14.3 Universal Resource Identifier Syntax

uri = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net-path | abs-path | rel-path
net-path = "//" net-loc [ abs-path ]
abs-path = "/" rel-path
rel-path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <any OCTET excluding ALPHA, DIGIT, reserverd, extra,
            safe, and unsafe>

14.4 RTSP-specific syntax

setup-response = response-line
                 date-type-header
                 *( nack-require-header
                  | nack-require-transport-header )
                  CRLF

redirect-response = response-line
                    date-type-header

session-response = response-line
                   date-type-header

play-response = response-line
                date-type-header

pause-response = response-line
                 date-type-header

message-body = *OCTET

accept-header = "Accept" ":" 1#media-type
allow-header = "Allow" ":" 1#method
blocksize-header = "Blocksize" ":" 1*DIGIT
content-length-header = "Content-Length" ":" 1*DIGIT
content-type-header = "Content-Type" ":" media-type
date-type-header = "Date" ":" rfc1123-date
location-header = "Location" ":" request-uri
require-header = "Require" ":" #parameters
transport-require-header = "Transport-Require" ":" #parameters
nack-require-header = "Nack-Require" ":" #parameters
nack-transport-require-header = "Nack-Transport-Require" ":" #parameters

auth-scheme = token
ip-address = <IP address in dotted-decimal form per RFC 1123>
port-number = 1*DIGIT
blocksize-value = 1*DIGIT
credentials = auth-scheme ":" #parameter
rfc1123-date = wkday "," SP date SP time SP "GMT"
date = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 12 Dec 1998)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"
month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun"
      | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"

15 Experimental

This service allows
either end section gathers parts of the connection to establish multiple virtual
sessions over a single transport connection. SCP also allows a
sender to indicate message boundaries, protocol which are less well understood
and allows a receiver require extensive further discussion.

15.1 Header Field Definitions

The following additional HTTP headers may be useful for RTSP:

   * Accept-Language
   * Cache-Control
   * From
   * Max-Forwards
   * Proxy-Authenticate
   * Proxy-Authorization
   * Public
   * Referer

15.1.1 Address

Designates address to
reject an incoming session.

Design goals

SCP allows send multimedia data to be sent with to.

     It appears that in almost all cases, the session establishment; destination address is
     the
recepient does not confirm successful connection establishment,
but may reject unsuccessful attempts. This simplifies same one where the design
of RTSP command originates from. If TCP is
     used for control, this also eliminates the protocol, and removes possibilities of
     pointing a data stream at an unsuspecting third party.

16 Security Considerations

The protocol offers the latency required opportunity for a con-
firmed operation.

Low overhead

SCP has a fixed overhead of 8 bytes per segment. This overhead is
only incurred once per segment, instead of once per packet.

Simple design remote-control denial-of-service
attack. The session protocol should be simple enough to implement attacker, using a forged source IP address, can ask for a
single application.

Protocol Description

Header Format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0| flags |               session ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        session length                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                             data                              /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

flags:
                    0x1 : SYN
                    0x2 : FIN
                    0x4 : RST
                    0x8 : PUSH

Protocol Operation

Session ID allocation
Each session
stream to be played back to that forged IP address.

Since there is allocated no relation between a session identifier. Session
Identifiers below 1024 are reserved. Session IDs allocated by
clients are even; those allocated byservers, odd.

Session establishment
A new session is established by setting the SYN bit in the first
message sent on that channel.

Graceful release

A session transport layer connection and an RTSP
session, it is ended by sending possible for a message malicious client to issue requests with the FIN bit set.
Each end
random session identifiers which would affect unsuspecting clients. This
does not require spoofing of network packet addresses. The server SHOULD
use a connection may be closed independently.

Disgraceful release
A large random session may identifier to make this attack more difficult.

Both problems can be terminated be prevented by sending a message with appropriate authentication.

In addition, the RST bit
set. All pending data for that security considerations outlined in [H15] apply.

A State Machines

The RTSP client and server state machines describe the behavior of the
protocol from session initialization through session termination.

[TBD: should be discarded

Message boundaries
A message boundary is marked by sending a message with we allow for the PUSH
bit set. The boundary is set at trivial case of a server that only implements
the final octet in this PLAY message,
including that octet.

Compressed Header SCP

 +-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+
 |1|P| IDL | LNL | session ID  | segment length |  data  |
 +-+-+-+-+-+-+-+-+-----//------+-------//-------+---//---+

P: 1 bit
Push bit. This denotes with no control.]

State is defined on a message boundry, which per object basis. An object is set at the
final octet in this message.

IDL: 3 bit
Length of uniquely identified by
the session ID field (as described below).

LNL: 3 bits
Length of stream URL AND the session length field (as described below). identifier. (A server may choose to generate
dynamic session ID: Variable number of bits, depending on IDL field
Identifier descriptions where the URL is unique for this session. The a particular
session ID value is relative to
1024, which is and thus may not need an explicit session identifier in the minimum non-reserved value.

 segment length: Variable number request
header.) Any request/reply using URLs denoting a session comprised of bits, depending
multiple streams will have an effect on LNL field.
Length of the payload in bytes.

IDL and LNL values: 3 bits

               value  Length individual states of Session ID or Segment Length field
               0x0    use previous value
               0x1    4 bits
               0x2    8 bits
               0x3    12 bits
               0x4    16 bits
               0x5    24 bits
               0x6    32 bits
               0x7    64 bits

IDL all the
substreams. For example:

Assuming the stream /coolmovie contains two substreams /coolmovie/audio and LNL values should be chosen so that byte alignment of
/coolmovie/video, then the
packet is guaranteed.

6.3 APPENDIX C - RTSP -Audio (Family ID =1 )
             Format descriptor (Parameter=1)
[Note: see "Compartmentalize following command:

  PLAY /coolmovie RTSP/1.0 559
  Session: 12345

will have an effect on the Protocol" states of coolmovie/audio and coolmovie/video.

     This example does not imply a standard way to represent
     substreams in URLs or a relation to the "RTSP
Open Issues" document filesystem. See Section
     3.2.

A.1 Client State Machine

A.1.1 Client States

These are defined as follows:

NULL:
     No state
INIT:
     GET or SETUP has been sent, waiting for discussion of reply.
READY:
     SETUP reply received OR after playing, PAUSE reply received.
PLAYING:
     PLAY reply received

A.1.2 Notes

In general, the possible split client transitions state on receipt of this appendix into specific replies.
After a separate document
(http://www.prognet.com/prognet/rt/openissues.html)]

[Note: see "Change Appendix C (families period of inactivity, state transitions back to NULL. "Inactivity"
is defined as one of stream types)"
in the "RTSP Open Issues" document for discussion following:

   * For state PLAYING, no data being received and/or lack of wellness
     information from the server.
   * The client stays in any other state continuously for more than a
series
     specific interval. The choice of proposed changes to this Appendix, such as
changing CODEC IDs interval is left to UUIDs, modifying the audio family,
and adding
     implementation.

If no explicit SETUP is required for the object (for example, it is
available via a video family
(http://www.prognet.com/prognet/rt/openissues.html)]

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          CODEC ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          NumChannels          |     Bits/Sample               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Samples Per Second                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Average Frame Size       |        Maximum Frame Size     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Samples Per Frame                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|       Frames Per Packet     |        Extra Bytes            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Number Of Frames                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      CODEC-specific Data                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                             :                                 :
:                             :                                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The above structure describes multicast group) , state begins at READY. In this case,
there are only two states, i.e READY and PLAYING.

A client MUST disregard messages with a generic compressed audio stream
for sequence number less than the RTSP Audio Family.

CODEC ID: The CODEC ID uniquely identifies last
one . If no message has been received, the codec which was
used to generate this audio data. CODEC ID's in first received message's
sequence number will be the range 0x00
through 0xffff are reserved for ACM (Audio Compression Manager
native to Microsoft Windows Operating systems) compatible/
interoperable codecs.

NumChannels: Use 1 for mono, 2 starting point.

A.1.3 State Table

In the NEXT STATE column, + indicates that the message was successful,
-indicates that it was unsuccessful.

STATE           MESSAGES                NEXT STATE(+)   NEXT STATE(-)

INIT            GET REPLY               INIT            NULL
                SETUP REPLY             READY           INIT
                REDIRECT                NULL            NULL
                BYE                     NULL            NULL
                OTHER                   INIT            INIT

READY           PLAY REPLY              PLAYING         READY
                SETUP REPLY             READY           INIT
                BYE                     NULL            NULL
                OTHER                   READY           READY

PLAYING         PAUSE REPLY             READY           PLAYING
                PLAY REPLY              PLAYING         CLOSED
                BYE                     NULL            NULL
                CLOSE REPLY             NULL            PLAYING
                OTHER                   PLAYING         PLAYING

This assumes that a PLAY during state PLAYING is an implicit PAUSE, PLAY.

     HS: BYE should be replaced by CLOSE.

A.2 Server State Machine

A.2.1 Server States

INIT:
     The initial state, no valid SETUP receieved.
READY:
     Last SETUP received was successful, reply sent or after playing, last
     PAUSE received was successful, reply sent.

PLAYING:
     Last PLAY received was successful, reply sent. Data actually being
     sent.

In general, server state transitions occur on receiving requests. On
receiving a BYE, state transitions back to INIT. After inactivity for stereo

Bits/Sample: Number of bits per sample as specified by the codec.
Codecs which do not need or do not have a well
period, state also transitions back to INIT. "Inactivity" is defined value as:

   * For states other than PLAYING, no messages for
this parameter may set this to zero.

Samples Per Second: Playback rate that object for each channel in
samples per second (hertz).

Average Frame Size: Frame a
     specific interval. The choice of interval is left to the smallest unit
     implementation.
   * In state PLAYING, lack of encoded audio
data that can be streamed wellness information from the server. Average Frame Size
represents client.(This
     information could be either RTCP or be requested by the typical size (in bytes) server by
     other means)

The REDIRECT message, when sent, is effective immediately. If a similar
change of location occurs at a frame. This family
does not support non byte-aligned frames.

Maximum Frame Size: Size certain time in bytes of the largest frame. For
constant bit rate codecs, future, this value is the same as the Average
Frame Size.

 Samples Per Frame: Number of samples of audio data encoded in
each frame. This family does not support variable duration frames.

P: If P is not set, then the audio data is planar and the client
has the option assumed
to request data packets of size which are
multiples of the average frame size. If P is set, the stream is
packetized (usually for variable bit rate data and live feeds),
then the size of the data packet is defined be indicated by frame size and
frames per packet (described below).

Frames Per Packet: For packetized formats, this represents the
number of frames in every data packet. session description. For planar formats, purposes of this table, a
REDIRECT is considered an unsuccessful GET.

A server MUST disregard messages with a hint to the client regarding sequence number less than the server preference.

Extra Bytes: This specifies last
one. If no message has been received, the first received message's sequence
number of bytes of codec specific
data that follow will be the fixed header.

Number of Frames: Total number of frames starting point.

SETUP is valid in the audio stream. For
non-seekable streams (e.g. live feeds), this states INIT and READY only. An error message should be set to
zero.

6.4 APPENDIX D - RTSP - Audio (Family ID =1 ) : Annotations
(Parameter=2)

[Note: see "Compartmentalize
returned in other cases. If no explicit SETUP is required for the object,
state starts at READY, ie. there are only two states READY and PLAYING.

A.2.2 State Table

In the Protocol" in NEXT STATE column, + indicates that the "RTSP message was successful,
-indicates that it was unsuccessful.

STATE           MESSAGES                NEXT STATE(+)   NEXT STATE(-)

INIT            GET                     INIT            INIT
                SETUP                   READY           INIT
                BYE                     INIT            INIT
                OTHER                   -               INIT

READY           PLAY                    PLAYING         READY
                SETUP                   READY           INIT
                CLOSE                   INIT            -
                BYE                     INIT            -
                OTHER                   -               READY

PLAYING         PLAY                    PLAYING         READY
                PAUSE                   READY           PLAYING
                CLOSE                   INIT            PLAYING
                BYE                     INIT            -
                OTHER                   -               PLAYING

B Open Issues" document for discussion Issues

   * Define text/rtsp-parameter MIME type.
   * Lots of the possible split inconsistencies need to be fixed: naming of this appendix into methods in state
     definition, syntax.
   * Allow changing of transport for a separate document
(http://www.prognet.com/prognet/rt/openissues.html)]

This payload data enables the server to communicate additional
information about the stream to the client. Examples of such
information include the authorof the clip, the clip name,
copyright information, creation date etc. The payload data is
organized as that's playing? May not be a list of information chunks. Each such chunk has an
identifier, length of
     great idea since the chunk same can be accomplished by tear down and
     re-setup.
   * How does the actual data itself.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Number of chunks                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Chunk Identifier (Chunk 0)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Number of Bytes (Chunk 0)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Chunk Data (Chunk 0)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                 :                             :
:                                 :                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Chunk Identifier (Chunk n-1)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Number of Bytes (Chunk n-1)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Chunk Data (Chunk n-1)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                 :                             :
:                                 :                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Identifier
This is a four character code identifying server get back to the chunk. For example,
`I''C''O''P' is used for copyright information which is
stored as client unless a null terminated string. `I''N''A''M' persistent
     connection is used for the
name used? Probably cannot, in general.
   * Cache and proxy behavior?
   * Session: or Set-Cookie: ?
   * Behavior of the audio clip. `I''U''R''L' serves all methods in state diagram.
   * Error message for method
   * When do relative RTSP URLs make sense?
   * Nack-require, etc. are dubious. This is getting awfully close to pass the URL
     HTTP extension mechanisms [16] in complexity, but is different.
   * Suggestion (HS): shelve REDIRECT method for now, until necessity
     becomes clear.
   * Use HTTP absolute path + Host field or do the CODEC installer. The client should use this URL if it
encounters a clip compressed with an unknown CODEC.

Any chunk with an unrecognized four character code should be
ignored by right thing and carry
     full URL, including host in request?

C Author Addresses

Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
electronic mail: schulzrinne@cs.columbia.edu

Anup Rao
Netscape Communications Corp.
USA
electronic mail: anup@netscape.com

Robert Lanphier
Progressive Networks
1111 Third Avenue Suite 2900
Seattle, WA 98101
USA
electronic mail: robla@prognet.com

D Acknowledgements

This draft is based on the client.

Number functionality of Bytes

Represents the length RTSP draft. It also borrows
format and descriptions from HTTP/1.1.

This document has benefited greatly from the comments of all those
participating in the chunk data. The chunk data should be
16 bit aligned.

6.5 APPENDIX E - Authors

Contacts:

At Netscape:              Anup Rao     <anup@netscape.com>
At Progressive Networks:  Rob Lanphier <robla@prognet.com>

[Note: this list will need MMUSIC-WG. In addition to be updated for the final
release of those already mentioned, the document]

The
following authors individuals have contributed to this document:

Martin Dunsmuir  <martind@prognet.com>
  General Manager Server Products,
  Progressive Networks
  1111 Third Avenue, Suite 2900
  Tel. 206 674 2700 (main #)

John K. Ho  <johnkho@netscape.com>
  Project Manager
  Netscape Communications Corp.
  685 E. Middlefield Rd.
  Mountain View, CA, 94043
  Tel. 415 254 1900 (main #)

Rob Lanphier  <robla@prognet.com>
  Program Manager
  Progressive Networks specification:

 Rahul Agarwal     Eduardo F. Llach  <eduardo@netscape.com>
  Manager, Media Server Team,
  Netscape Communications Corp.
 Bruce Butterfield Rob McCool  <robm@netscape.com>
  Technical Team Leader, Media Server
  Netscape Communications Corp.
 Martin Dunsmuir   Sujal Patel
 Mark Handley      Igor Plotnikov  <igor@netscape.com>
  Technical Team Leader, Media Server
  Netscape Communications Corp.

Anup Rao
  Member, Technical Staff
  Netscape Communications Corp.
 Peter Haight      Pinaki Shah
  Member, Technical Staff
  Netscape Communications Corp.
 Brad Hefta-Gaub   Jeff Smith
 John K. Ho        Alexander Sokolsky
  Member, Technical Staff
  Netscape Communications Corp.
 Ruth Lang         Dale Stammen
  Lead Saxophone
  Progressive Networks
 Stephanie Leif    John Francis Stracke
  Senior LiveMedia Architect
  Netscape Communications Corp.

References

1     D. Kristol and L. Montulli, ``HTTP state management mechanism,'' RFC
     2109, Internet Engineering Task Force, Feb. 1997.

2     F. Yergeau, G. Nicol, G. Adams, and M. Duerst, ``Internationalization
     of the hypertext markup language,'' RFC 2070, Internet Engineering
     Task Force, Jan. 1997.

3     S. Bradner, ``Key words for use in RFCs to indicate requirement
     levels,'' Internet Draft, Internet Engineering Task Force, Jan. 1997.
     Work in progress.

4     R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee,
     ``Hypertext transfer protocol - HTTP/1.1,'' RFC 2068, Internet
     Engineering Task Force, Jan. 1997.

5     A. Freier, P. Karlton, and P. Kocher, ``The TLS protocol,'' Internet
     Draft, Internet Engineering Task Force, Dec. 1996. Work in progress.

6     J. Franks, P. Hallam-Baker, J. Hostetler, P. A. Luotonen, and E. L.
     Stewart, ``An extension to HTTP: digest access authentication,'' RFC
     2069, Internet Engineering Task Force, Jan. 1997.

7     J. Postel, ``User datagram protocol,'' STD 6, RFC 768, Internet
     Engineering Task Force, Aug. 1980.

8     R. Hinden and C. Partridge, ``Version 2 of the reliable data protocol
     (RDP),'' RFC 1151, Internet Engineering Task Force, Apr. 1990.

9     J. Postel, ``Transmission control protocol,'' STD 7, RFC 793,
     Internet Engineering Task Force, Sept. 1981.

10    M. Handley, H. Schulzrinne, and E. Schooler, ``SIP: Session
     initiation protocol,'' Internet Draft, Internet Engineering Task
     Force, Dec. 1996. Work in progress.

11    P. McMahon, ``GSS-API authentication method for SOCKS version 5,''
     RFC 1961, Internet Engineering Task Force, June 1996.

12    D. Crocker, ``Augmented BNF for syntax specifications: ABNF,''
     Internet Draft, Internet Engineering Task Force, Oct. 1996. Work in
     progress.

13    R. Elz, ``A compact representation of IPv6 addresses,'' RFC 1924,
     Internet Engineering Task Force, Apr. 1996.

14    T. Berners-Lee, ``Universal resource identifiers in WWW: a unifying
     syntax for the expression of names and addresses of objects on the
     network as used in the world-wide web,'' RFC 1630, Internet
     Engineering Task Force, June 1994.

15    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.

16    D. Connolly, ``PEP: an extension mechanism for http,'' Internet
     Draft, Internet Engineering Task Force, Jan. 1997. Work in progress.