\section{Querying for Capabilities}
\label{sec:query-for-capabilities}

The SIP method {\OPTIONS} allows a UA to query another UA or a proxy
server as to its capabilities.  This allows a client to discover
information about the supported methods, content types, 
extensions, codecs, etc. without "ringing" the other party. For example,
before a client inserts a \header{Require} header field into an
{\INVITE} listing an option that it is not certain the destination UAS
supports, the client can query the destination UAS with an {\OPTIONS} to
see if this option is returned in a \header{Supported} header field.  \begin{changebar}
All UAs {\MUST} support the {\OPTIONS} method. \end{changebar}

The target of the {\OPTIONS} request is identified by the
\header{Request-URI}, which could identify another UA or a SIP
server.  If the {\OPTIONS} is addressed to a proxy server, the
\header{Request-URI} is set without a user part, similar to the way a
\header{Request-URI} is set for a {\REGISTER} request.

Alternatively, a server receiving an {\OPTIONS} request with a
\header{Max-Forwards} header field value of 0 {\MAY} respond to the request
regardless of the \header{Request-URI}.

\motivation{This behavior is common with HTTP/1.1.  This behavior can be
used as a ``traceroute'' functionality to check the capabilities of
individual hop servers by sending a series of {\OPTIONS} requests with
incremented \header{Max-Forwards} values.}

As is the case for general UA behavior, the transaction layer can return
a timeout error if the {\OPTIONS} yields no response.  This may indicate
that the target is unreachable and hence unavailable.

An {\OPTIONS} request {\MAY} be sent as part of an established dialog to
query the peer on capabilities that may be utilized later in the dialog. 

\subsection{Construction of {\OPTIONS} Request}
\label{sec:query-for-capabilities:request}

An {\OPTIONS} request is constructed using the standard rules for a SIP
request as discussed Section~\ref{sec:general:gen}.

A \header{Contact} header field {\MAY} be present in an {\OPTIONS}.

An \header{Accept} header field {\SHOULD} be included to indicate the
type of message body the UAC wishes to receive in the
response.  Typically, this is set to a format that is used to describe
the media capabilities of a UA, such as SDP (application/sdp). 

The response to an {\OPTIONS} request is assumed to be scoped to the
\header{Request-URI} in the original request.  However, only when an
{\OPTIONS} is sent as part of an established dialog is it guaranteed
that future requests will be received by the server that generated the
{\OPTIONS} response. 

Example {\OPTIONS} request:

\begin{changebar}
\begin{verbatim}
  OPTIONS sip:carol@chicago.com SIP/2.0
  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
  Max-Forwards: 70
  To: <sip:carol@chicago.com>
  From: Alice <sip:alice@atlanta.com>;tag=1928301774
  Call-ID: a84b4c76e66710
  CSeq: 63104 OPTIONS
  Contact: <sip:alice@pc33.atlanta.com>
  Accept: application/sdp
  Content-Length: 0
\end{verbatim}
\end{changebar}


\subsection{Processing of OPTIONS Request}
\label{sec:query-for-capabilities:response}

The response to an {\OPTIONS} is constructed using the standard rules
for a SIP response as discussed in Section~\ref{sec:general:serv-resp}. 
The response code chosen 
\begin{changebar}
{\MUST} be
\end{changebar} 
the same that would have been chosen had the
request been an {\INVITE}.  That is, a 200 (OK) would be returned if the
UAS is ready to accept a call, a 486 (Busy Here) would be returned if
the UAS is busy, etc.  This allows an {\OPTIONS} request to be used to
determine the basic state of a UAS, which can be an indication of
whether the UAC will accept an {\INVITE} request.

An {\OPTIONS} request received within a dialog generates a 200 (OK)
response that is identical to one constructed outside a dialog and does
not have any impact on the dialog.

This use of {\OPTIONS} has limitations due the differences in proxy
handling of {\OPTIONS} and {\INVITE} requests.  While a forked {\INVITE}
can result in multiple 200 (OK) responses being returned, a forked
{\OPTIONS} will only result in a single 200 (OK) response, since it is
treated by proxies using the non-{\INVITE} handling.  See \begin{changebar}
Section~\ref{sec:proxy-response-processing} for the normative details. \end{changebar}

If the response to an {\OPTIONS} is generated by a proxy server, the
proxy returns a 200 (OK) listing the capabilities of the server.  The
response does not contain a message body.

\header{Allow}, \header{Accept}, \header{Accept-Encoding},
\header{Accept-Language}, and \header{Supported} header fields {\SHOULD}
be present in a 200 (OK) response to an {\OPTIONS} request.  If the
response is generated by a proxy, the \header{Allow} header field
{\SHOULD} be omitted as it is ambiguous since a proxy is method
agnostic.  \header{Contact} header fields {\MAY} be present in a 200
(OK) response and have the same semantics as in a 3xx response.  That is,
they may list a set of alternative names and methods of reaching the
user.  A \header{Warning} header field {\MAY} be present.

A message body {\MAY} be sent, the type of which is determined by the
\header{Accept} header field in the {\OPTIONS} request (application/sdp 
is the default if the
\header{Accept} header field is not present).  If the types include one that
can describe media capabilities, the UAS {\SHOULD} include a body in the
response for that purpose.  Details on construction of such a body in
the case of application/sdp are described 
in~\citenorm{draft-ietf-mmusic-sdp-offer-answer}. 

Example {\OPTIONS} response generated by a UAS (corresponding to the
request in Section~\ref{sec:query-for-capabilities:request}):

\begin{changebar}
\begin{verbatim}
  SIP/2.0 200 OK
  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
   ;received=192.0.2.4
  To: <sip:carol@chicago.com>;tag=93810874
  From: Alice <sip:alice@atlanta.com>;tag=1928301774
  Call-ID: a84b4c76e66710
  CSeq: 63104 OPTIONS
  Contact: <sip:carol@chicago.com>
  Contact: <mailto:carol@chicago.com>
  Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
  Accept: application/sdp
  Accept-Encoding: gzip
  Accept-Language: en
  Supported: foo
  Content-Type: application/sdp
  Content-Length: 274

  (SDP not shown)
\end{verbatim}
\end{changebar}

