\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 send 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 TBD), 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, the timeout value MAY be set
to an arbitrarily large value.  \motivation{This can greatly increase
responsiveness for proxies operating in local-area networks with small
RTTs.  The mechanism is defined such that the client implementation does
not have be aware of whether a reliable or unreliable transport protocol
is being used.  It is probably a bad idea to have two reliability
mechanisms on top of each other, although the RTSP RTT estimate is
likely to be larger than the TCP estimate.}

Each request carries a sequence number, which is incremented by one for
each request transmitted.  If a request is repeated because of lack of
acknowledgement, the sequence number is incremented.  \motivation{This
avoids ambiguities when computing round-trip time estimates.} [TBD:  An
initial sequence number negotiation needs to be added for UDP;
otherwise, a new stream connection may see 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
{\sf TEARDOWN} followed by a {\sf PLAY} has quite a different effect than
the reverse.  Similarly, if a {\sf 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 retransmissions
are incremented (to allow easy RTT estimation), the receiver cannot just
ignore out-of-order packets.  [TBD:  This problem could be fixed by
including both a sequence number that stays the same for retransmissions
and a timestamp for RTT estimation.]

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 Content-Length header whenever that message
contains a payload.  Otherwise, an RTSP packet is terminated with an empty
line immediately following the last message header.
