\section{Protocol Parameters}
\label{sec:parameters}

\subsection{RTSP Version}

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

\subsection{RTSP URL}
\label{sec:url}

The ``rtsp'' and ``rtspu'' schemes are used to refer to
network resources via the RTSP protocol.  This section defines the
scheme-specific syntax and semantics for RTSP URLs.

\begin{syntax}
rtsp\_URL &=& ( "rtsp:" $|$ "rtspu:" ) \\
&& "//" host [ ":" port ] [ abs\_path ] \\
host    &=& $<$A legal Internet host domain name of IP address\\
&&           (in dotted decimal form), as defined by Section 2.1\\
&&           of RFC 1123 \cite{rfc1123}$>$\\
port    &=& *DIGIT\\
\end{syntax}

\header{abs\_path} is defined in [H3.2.1].

\motivation{Note that fragment and query identifiers do not have a
well-defined meaning at this time, with the interpretation left to the
RTSP server.}

The scheme \header{rtsp} requires that commands are issued via a reliable
protocol (within the Internet, TCP), while the scheme \header{rtspu}
identifies an unreliable protocol (within the Internet, UDP).  

If the \header{port} is empty or not given, port 554 is assumed.  The
semantics are that the identified resource can be controlled by RTSP at
the server listening for TCP (scheme ``rtsp'') connections or UDP
(scheme ``rtspu'') packets on that \header{port} of \header{host}, and
the \header{Request-URI} for the resource is \header{rtsp\_URL}.

The use of IP addresses in URLs SHOULD be avoided whenever possible (see
RFC 1924 \cite{rfc1924}).

A presentation or a stream is identified by a textual media identifier,
using the character set and escape conventions [H3.2] of URLs (RFC 1738
\cite{rfc1738}).  URLs may refer to a stream or an aggregate of streams,
i.e., a presentation.  Accordingly, requests described in
Section~\ref{sec:methods} can apply to either the whole presentation or
an individual stream within the presentation.  Note that some request
methods can only be applied to streams, not presentations and vice
versa.

For example, the RTSP URL:
\begin{verbatim}
  rtsp://media.example.com:554/twister/audiotrack
\end{verbatim}
identifies the audio stream within the presentation ``twister'', which
can be controlled via RTSP requests issued over a TCP connection to port
554 of host {\tt media.example.com}.

Also, the RTSP URL:
\begin{verbatim}
  rtsp://media.example.com:554/twister
\end{verbatim}
identifies the presentation ``twister'', which may be composed of audio and 
video streams.

\motivation {This does not imply a standard way to reference streams in
URLs.  The presentation description defines the hierarchical
relationships in the presentation and the URLs for the individual
streams.  A presentation description may name a stream ``a.mov'' and the
whole presentation ``b.mov''.}

The path components of the RTSP URL are opaque to the client and do not
imply any particular file system structure for the server.

\motivation{This decoupling also allows presentation descriptions to be
used with non-RTSP media control protocols simply by replacing the
scheme in the URL.}

\subsection{Conference Identifiers}
\label{sec:confid}

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 globally
unique. For H.323, the conferenceID value is to be used.

\begin{syntax}
conference-id &=& 1*xchar
\end{syntax}

\motivation{Conference identifiers are used to allow RTSP sessions to
obtain parameters from multimedia conferences the media server is
participating in.  These conferences are created by protocols outside
the scope of this specification, e.g., H.323 \cite{H.323} or SIP
\cite{rfc2543}.  Instead of the RTSP client explicitly providing
transport information, for example, it asks the media server to use the
values in the conference description instead.}

\subsection{Session Identifiers}
\label{sec:session-id}

Session identifiers are opaque strings of arbitrary length.  Linear
white space must be URL-escaped.  A session identifier MUST be chosen
randomly and MUST be at least eight octets long to make guessing it
more difficult. (See Section~\ref{sec:security}.)

\begin{syntax}
session-id &=& 8*( ALPHA $|$ DIGIT $|$ safe )\\
\end{syntax}

\subsection{SMPTE Relative Timestamps}
\label{sec:smpte}

A SMPTE relative timestamp expresses time relative to the start of the
clip.  Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy.  The time code has the format
\begin{center}
  {\it hours:minutes:seconds:frames.subframes},
\end{center}
with the origin at the start of the clip.  The default smpte format
is``SMPTE 30 drop'' format, with frame rate is 29.97 frames per second.
Other SMPTE codes MAY be supported (such as "SMPTE 25") through the use of
alternative use of "smpte time".  For the ``frames'' field in the time
value can assume the values 0 through 29.  The difference between 30 and
29.97 frames per second is handled by dropping the first two frame indices
(values 00 and 01) of every minute, except every tenth minute.  If the
frame value is zero, it may be omitted.  Subframes are measured in
one-hundredth of a frame.

\begin{syntax}
smpte-range &=& smpte-type "=" smpte-range-spec\\
smpte-range-spec  &=& ( smpte-time "-" [ smpte-time ] ) $|$ ( "-" smpte-time )\\
smpte-type        &=& "smpte" $|$ "smpte-30-drop" $|$ "smpte-25"
                {\rm ; other timecodes may be added}\\
smpte-time        &=& 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT 
                [ ":" 1*2DIGIT ] [ "." 1*2DIGIT ]
\end{syntax}

\noindent Examples:
\begin{verbatim}
  smpte=10:12:33:20-
  smpte=10:07:33-
  smpte=10:07:00-10:07:33:05.01
  smpte-25=10:07:00-10:07:33:05.01
\end{verbatim}

\subsection{Normal Play Time}
\label{sec:npt}

Normal play time (NPT) indicates the stream absolute position relative
to the beginning of the presentation.  The timestamp consists of a
decimal fraction.  The part left of the decimal may be expressed in
either seconds or hours, minutes, and seconds.  The part right of the
decimal point measures fractions of a second.

The beginning of a presentation corresponds to 0.0 seconds.  Negative
values are not defined.  The special constant \header{now} is defined as
the current instant of a live event.  It may be used only for live
events.

NPT is defined as in DSM-CC:  ``Intuitively, NPT is the clock the viewer
associates with a program.  It is often digitally displayed on a VCR. 
NPT advances normally when in normal play mode (scale = 1), advances at
a faster rate when in fast scan forward (high positive scale ratio),
decrements when in scan reverse (high negative scale ratio) and is fixed
in pause mode.  NPT is (logically) equivalent to SMPTE time codes.''
\cite{ISO9511:13818-6}

\begin{syntaxwcomment}
npt-range       &=& ["npt" "="] npt-range-spec\\
		& & {\rm ; implementations SHOULD use npt= prefix, but SHOULD}\\
		& & {\rm ; be prepared to interoperate with RFC 2326}\\
 		& & {\rm ; implementations which don't use it }\\
npt-range-spec  &=& ( npt-time "-" [ npt-time ] ) $|$ ( "-" npt-time )\\
npt-time        &=& "now" $|$ npt-sec $|$ npt-hhmmss\\
npt-sec         &=& 1*DIGIT [ "." *DIGIT ]\\
npt-hhmmss      &=& npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]\\
npt-hh          &=& 1*DIGIT &; any positive number\\
npt-mm          &=& 1*2DIGIT  &; 0-59\\
npt-ss          &=& 1*2DIGIT  &; 0-59
\end{syntaxwcomment}

\noindent Examples:
\begin{verbatim}
  npt=123.45-125
  npt=12:05:35.3-
  npt=now-
\end{verbatim}

\motivation{The syntax conforms to ISO 8601.  The npt-sec notation is
optimized for automatic generation, the ntp-hhmmss notation for
consumption by human readers.  The ``now'' constant allows clients to
request to receive the live feed rather than the stored or time-delayed
version. This is needed since neither absolute time nor zero time are
appropriate for this case.}

\subsection{Absolute Time}
\label{sec:clock}

Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT).
Fractions of a second may be indicated.

\begin{syntaxwcomment}
utc-range    &=& "clock" "=" utc-time "-" [ utc-time ]\\
utc-time     &=& utc-date "T" utc-time "Z"\\
utc-date     &=& 8DIGIT                  &; $<$ YYYYMMDD $>$\\
utc-time     &=& 6DIGIT [ "." fraction ] &; $<$ HHMMSS.fraction $>$\\
\end{syntaxwcomment}

\noindent
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds UTC:
\begin{verbatim}
  19961108T143720.25Z
\end{verbatim}

\subsection{Option Tags}
\label{sec:option_tags}

Option tags are unique identifiers used to designate new options in
RTSP.  These tags are used in in \header{Require}
(Section~\ref{sec:Require}) and \header{Proxy-Require}
(Section~\ref{sec:Proxy-Require}) header fields.

\noindent
Syntax:
\begin{syntax}
option-tag &=& token\\
\end{syntax}

The creator of a new RTSP option should either prefix the option with a
reverse domain name (e.g., ``com.foo.mynewfeature'' is an apt name for a
feature whose inventor can be reached at ``foo.com''), or register the
new option with the Internet Assigned Numbers Authority (IANA).

\subsubsection{Registering New Option Tags with IANA}

When registering a new RTSP option, the following information should
be provided:

\begin{itemize}
\item Name and description of option.  The name may be of any length,
but SHOULD be no more than twenty characters long. The name MUST not
contain any spaces, control characters or periods.

\item Indication of who has change control over the option (for
example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of companies);

\item A reference to a further description, if available, for example
(in order of preference) an RFC, a published paper, a patent filing, a
technical report, documented source code or a computer manual;

\item For proprietary options, contact information (postal and email
address);
\end{itemize}
