\section{Usage of SDP}
\label{sec:sdp}

By default, the $n$th media session in a unicast {\INVITE} request will
become a single RTP session with the $n$th media session in the
response.  Thus, the callee should be careful to order media
descriptions appropriately.

It is assumed that if caller or callee include a particular media type,
they want to both send and receive media data.  If the callee does not
want to {\em send} a particular media type, it marks the media
entry as {\em recvonly}.  If the callee does not want to {\em receive} a
particular media type, it may mark it as {\em sendonly}.  If the callee
wants to neither receive nor send a particular media type, it 
sets the port to zero.  (RTCP ports are not needed in this case.)

The caller includes all media types that it is willing to send so
that the receiver can provide matching media descriptions.

The callee sets the port to zero if callee and caller only want to
receive a media type.

Either party can set the ``c'' destination address to zero (0.0.0.0) if
it wants to signal to the other party to stop sending media data.  This
implements a (far-side) ``mute'' or ``hold'' functionality.

\motivation{The SDP fields ``s'' and the SIP \header{Subject} header
have different meanings when inviting to a multicast session.  The SDP
field describes the subject of the multicast session, while the SIP
\header{Subject} header describes the reason for the invitation.  The
example in Section~\ref{sec:invite-example} illustrates this point.  For
invitations to two-party sessions, the SDP ``s'' field {\MAY} be left
empty.  The ``o'' field is not strictly necessary for two-party
sessions, but {\MUST} be present to allow re-use of SDP-based tools.}
