\section {Use of SDP for  RTSP Session Descriptions}
\label{sec:sdpusage}


The Session Description Protocol(SDP \cite{Hand9611:SDP}) may be used to 
describe streams or presentations in RTSP. Such usage is limited to specifying means of access and encoding(s) for:

\begin{itemize}
\item Scenario A: A  presentation  comprised of streams from one or more servers. Such a 
description is typically retrieved by HTTP or other non-RTSP means. However,
they MAY be received with ANNOUNCE methods.
\item Scenario B: A container whose media segments are transported and controlled as 
individual RTSP streams. Such a description is typically returned in reply 
to a DESCRIBE request on a URL, or
received in an ANNOUNCE method. A single stream is a special case of 
this scenario with just one stream.
\end{itemize}

Specifically, this appendix addresses the usage of SDP(for example, embedded 
in a web
page) that triggers  a RTSP session, and the usage  in replies to 
RTSP DESCRIBE requests. However, it  does not address the issue of media or 
encoding negotiation within such descriptions.


\subsection{Specification}

The terms ``session-level'', ``media-level'' and other key/attribute names
and values used in this appendix are as defined in \cite{Hand9611:SDP}. 
SDP fields not specifically mentioned in this section are assumed to have 
their usual meaning.

\subsubsection{Control URL} 
The ``c='' field is used to convey the control URL. Within the network 
type ``IN'' defined for this field, the address type ``URL'' is used to 
convey that the client needs to use the specified protocol, host, port 
and URI to access and control the session. As explained below, this field
is used at the  media-level.

\begin{verbatim}
Example:
  c=IN URL rtsp://example.com/foo
\end{verbatim}

\subsubsection{Media streams}
The ``m='' field is used to  enumerate the streams. It is expected 
that all the specified streams will be rendered with appropriate 
synchronization.
If the session is unicast, the port number simply serves as a recommendation,
and would still need to be conveyed to the server via a SETUP request. The port
number may be specified as 0, in which case the client makes the choice of the
port.
 
\begin{verbatim}
Example:
  m=audio 0 RTP/AVP 31
\end{verbatim}


\subsubsection{Payload type(s)}

The payload type(s) are specified in the ``m='' field. In case the payload 
type is a static payload type from RFC 1890(\cite{rfc1890}), no other 
information is required. In case it is a dynamic payload type, the media
attribute ``rtpmap'' is used to specify what the media is. The 
``encoding name'' within the ``rtpmap'' attribute may be one of those 
specified in RFC 1890(Sections 5 and 6), or an experimental encoding with a 
``X-'' prefix as specified in \cite{Hand9611:SDP}. Codec-specific parameters are 
not specified in this field but the ``fmtp'' attribute described below.
Implementors seeking to register
new encodings should follow the procedure in RFC 1890. If the media type is
not suited to the RTP AV profile, then it is recommended that a new profile
be created and the appropriate profile name must be used in lieu of 
``RTP/AVP'' in the ``m='' field. 
An informational document may be published  in lieu of this if 
the usage is expected to be limited or experimental. 


\subsubsection{Format specific parameters}

This is accomplished using the ``fmtp'' media attribute. The syntax of the
``fmtp'' attribute is specific to the encoding(s) that the attribute refers
to. This is with the exception of the number of samples per packet, which is
conveyed using the ``ptime'' attribute.


\subsubsection{Time of availability}

It is required that suitable values for the start and stop times for the
``t='' field be used for both scnearios. In Scenario B, the server SHOULD 
indicate a stop time value for which it guarantees the description to be 
valid, and a start time that is equal to or before the time at which 
the DESCRIBE request 
was received. In Scenario A, the values should reflect the actual period for
which the session is avaiable, and not depend on other means(such as the 
life of the web page containing the description) for this purpose.

\subsubsection{Originator of session}

In Scenario A, the address in the ``o='' field MUST accurately reflect the
source of session creator.(for example, a HTTP server if the description was 
retreived by HTTP). In Scenario B, it MUST be that of the RTSP server that 
the SDP description is received from.

\subsubsection{Conference control}
SDP descriptions as used with RTSP are not expected to result in a client
participating in a conference.(A client may however be a participant in
a conference by other means than RTSP). Hence the usage of the 
media attributes  ``type'', ``sendrecv'' and ``sendonly'' in scenarios A, B
have no well-defined
meaning at this time and should be ignored. 


\subsection{Scenario A}

Multiple media sections are specified, and each section MUST  have the control
URL specified via the ``c=''field. 

\begin{verbatim}
Example:

v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I came from a web page
t=0 0
m=video 8002 RTP/AVP 31
c=IN URL rtsp://audio.com/movie.aud
m=audio 8004 RTP/AVP 3
c=IN URL rtsp://video.com/movie.vid
\end{verbatim}

Note that the control URL in this case implies that the client establishes
seperate RTSP control sessions to the servers audio.com and video.com.

\subsection{Scenario B}

In this scenario, a media-level ``c='' field is  used in a different manner.
It specifies the
relative URI for the stream, which is to be used in conjunction with
the URL in the DESCRIBE request that returned the description. 
For RTSP control, this also 
signifies that a single RTSP session is to be used for controlling the 
component(s). If the session comprises only a single stream, the 
media-level ``c='' field is omitted altogether. In case more than one stream
is present, the ``c='' field MUST be used.

\begin{verbatim}
Example:

v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I contain
i=<more info>
t=0 0
m=video 8002 RTP/AVP 31
c=IN URL trackID=1
m=audio 8004 RTP/AVP 3
c=IN URL trackID=2
\end{verbatim}

In this example, the client is required to establish a single RTSP session 
to the server(assumed to be example.com),
and uses the URLs rtsp://example.com/movie/trackID=1 and
rtsp://example.com/movie/trackID=2 to setup and control the media streams.

