\section{Connections}
\label{sec:connections}

RTSP requests can be transmitted in several different ways:

\begin{itemize}
\item persistent transport connections used for several request-response
transactions;
\item one connection per request/response transaction;
\item connectionless mode.
\end{itemize}

The type of transport connection is defined by the RTSP URI
(Section~\ref{sec:url}). For the scheme ``rtsp'', a persistent
connection is assumed, while the scheme ``rtspu'' calls for RTSP
requests to be sent without setting up a connection.

Unlike HTTP, RTSP allows the media server to send requests to the media
client.  However, this is only supported for persistent connections, as
the media server otherwise has no reliable way of reaching the client. 
Also, this is the only way that requests from media server to client are
likely to traverse firewalls.

\subsection{Pipelining}

A client that supports persistent connections or connectionless mode MAY
``pipeline'' its requests (i.e., send multiple requests without waiting
for each response).  A server MUST send its responses to those requests
in the same order that the requests were received.

\subsection{Reliability and Acknowledgements}

Requests are acknowledged by the receiver unless they are sent to a
multicast group.  If there is no acknowledgement, the sender may resend
the same message after a timeout of one round-trip time (RTT).  The
round-trip time is estimated as in TCP (RFC 1123) \cite{rfc1123}, with
an initial round-trip value of 500 ms.  An implementation MAY cache the
last RTT measurement as the initial value for future connections.

If a reliable transport protocol is used to carry RTSP, requests MUST
NOT be retransmitted; the RTSP application MUST instead rely on the
underlying transport to provide reliability.

\motivation{
If both the underlying reliable transport such as TCP and the RTSP
application retransmit requests, it is possible that each packet loss
results in two retransmissions.  The receiver cannot typically take
advantage of the application-layer retransmission since the transport
stack will not deliver the application-layer retransmission before the
first attempt has reached the receiver.  If the packet loss is caused by
congestion, multiple retransmissions at different layers will exacerbate
the congestion.

If RTSP is used over a small-RTT LAN, standard procedures for optimizing
initial TCP round trip estimates, such as those used in T/TCP (RFC 1644)
\cite{rfc1644}, can be beneficial.}

The \header{Timestamp} header (Section~\ref{sec:Timestamp}) is used to
avoid the retransmission ambiguity problem \cite[p.~301]{Stev94:TCP} and
obviates the need for Karn's algorithm.

Each request carries a sequence number in the \header{CSeq} header
(Section~\ref{sec:CSeq}), which is incremented by one for each distinct
request transmitted.  If a request is repeated because of lack of
acknowledgement, the request MUST carry the original sequence number
(i.e., the sequence number is {\em not} incremented).

Systems implementing RTSP MUST support carrying RTSP over TCP and MAY
support UDP.  The default port for the RTSP server is 554 for both
UDP and TCP.

A number of 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 message MUST contain a \header{Content-Length} header field
whenever that message contains a payload.  Otherwise, an RTSP packet is
terminated with an empty line immediately following the last message
header.
