\section{General User Agent Behavior}
\label{sec:ua}

A user agent represents an end system.  It contains a user agent client
(UAC), which generates requests, and a user agent server (UAS), which
responds to them.  A UAC is capable of generating a request based on
some external stimulus (the user clicking a button, or a signal on a
PSTN line) and processing a response.  A UAS is capable of receiving a
request and generating a response based on user input, external
stimulus, the result of a program execution, or some other mechanism.

When a UAC sends a request, the request passes through some number of proxy
servers, which forward the request towards the UAS.  When the UAS
generates a response, the response is forwarded towards the UAC. 

UAC and UAS procedures depend strongly on two factors.  First, based on whether
the request or response is inside or outside of a dialog, and second,
based on the method of a request.  Dialogs are discussed thoroughly in
Section~\ref{sec:dialog}; they represent a peer-to-peer relationship
between user agents and are established by specific SIP methods, such
as {\INVITE}. 

In this section, we discuss the method-independent rules for UAC and UAS
behavior when processing requests that are outside of a dialog.  This
includes, of course, the requests which themselves establish a dialog. 

Security procedures for requests and responses outside of a dialog are
described in Section~\ref{sec:security}.  Specifically, mechanisms exist
for the UAS and UAC to mutually authenticate.  A limited set of privacy
features are also supported through encryption of bodies using S/MIME. 

\subsection{UAC Behavior}
\label{sec:general:req}

This section covers UAC behavior outside of a dialog.

\subsubsection{Generating the Request}
\label{sec:general:gen}

A valid SIP request formulated by a UAC {\MUST} at a minimum contains the
following header fields:  \header{To}, \header{From}, \header{CSeq},
\header{Call-ID}, \header{Max-Forwards}, and \header{Via}; all of these
header fields are mandatory in all SIP messages.  These six header fields 
are the
fundamental building blocks of a SIP message, as they jointly provide
for most of the critical message routing services including the
addressing of messages, the routing of responses, limiting message
propagation, ordering of messages, and the unique identification of
transactions.  These header fields are in addition to the mandatory request
line, which contains the method, \header{Request-URI}, and SIP version. 

Examples of requests sent outside of a dialog include an {\INVITE} to 
establish a session (Section~\ref{sec:initiate}) and an {\OPTIONS} to 
query for capabilities (Section~\ref{sec:query-for-capabilities}).

\paragraph{\header{Request-URI}}
\label{sec:general:uac:header:ruri}

The initial \header{Request-URI} of the message {\SHOULD} be set to the 
value of the URI in the \header{To} field. One notable exception is the 
{\REGISTER} method; behavior for setting the \header{Request-URI} of 
{\REGISTER} is given in Section~\ref{sec:reg}. 
\begin{changebar}
It may also be undesirable for privacy reasons or convenience to set 
these fields to the same value (especially if the originating UA
expects that the \header{Request-URI} will be changed during transit).
\end{changebar}

In some special circumstances, the presence of a pre-existing route
set can affect the \header{Request-URI} of the message. A pre-existing
route set is an ordered set of URIs that identify a chain of servers,
to which a UAC will send outgoing requests that are outside of a
dialog.  Commonly, they are configured on the UA by a user or
service provider manually, or through some other non-SIP mechanism. When a
provider wishes to configure a UA with an outbound proxy, it is
{\RECOMMENDED} that this be done by providing it with a pre-existing
route set with a single URI, that of the outbound proxy. 

When a pre-existing route set is present,
the procedures for populating the \header{Request-URI} and
\header{Route} header field detailed in
Section~\ref{sec:dialog:uac:generate} 
{\MUST} be followed,
even though there is no dialog. 


\paragraph{\header{To}}
\label{sec:general:uac:header:to}

The \header{To} header field first and foremost specifies the desired
``logical'' recipient of the request, or the address-of-record of the
user or resource that is the target of this request.  This may or may
not be the ultimate recipient of the request.  The \header{To} header
field {\MAY} contain a SIP or SIPS URI, but it may also make use of
other URI schemes (the tel URL (RFC~2806~\citenorm{rfc2806}), for
example) when appropriate.  All SIP implementations {\MUST} support the
SIP and URI scheme.  Any implementation that supports TLS {\MUST}
support the SIPS URI scheme.  The \header{To} header field allows for a
display name.

A UAC may learn how to populate the \header{To} header field for a
particular request in a number of ways. Usually the user will suggest
the \header{To} header field through a human interface, perhaps
inputting the URI manually or selecting it from some sort of address
book.  Frequently, the user will not enter a complete
URI, but rather a string of digits or letters (for example, ``bob''). It is
at the discretion of the UA to choose how to interpret this
input. Using the string to form the user part of a SIP URI implies that the UA
wishes the name to be resolved in the domain to the right-hand side (RHS)
of the at-sign in the SIP URI (for instance, sip:bob@example.com). 
\begin{changebar} Using the string to form the user part of a SIPS URI
implies that the UA wishes to communicate securely, and that the 
name is to be resolved in the domain to the RHS of the at-sign. \end{changebar}
The RHS
will frequently be the home domain of the user, which allows for the
home domain to process the outgoing request. This is useful for
features like ``speed dial'' that require interpretation of the user
\begin{changebar}
part in the home domain. The tel URL may be used when the UA does not wish
to specify the domain that should interpret a telephone number that has
been inputted by the user. Rather,
\end{changebar}
each domain through which the request passes would be given that
opportunity. As an example, a user in an airport might log in and
send requests through an outbound proxy in the airport. If they enter
``411'' (this is the phone number for local directory assistance in
the United States), that needs to be interpreted and processed by the
outbound proxy in the airport, not the user's home domain. In this
case, tel:411 would be the right choice. 

A request outside of a dialog {\MUSTNOT} contain a tag; the tag in the 
\header{To} field of a request identifies the peer of the dialog. Since no 
dialog is established, no tag is present.

For further information on the \header{To} header field, see
Section~\ref{sec:To}.  The following is an example of valid \header{To}
header field:
\begin{verbatim}
  To: Carol <sip:carol@chicago.com>
\end{verbatim}

\paragraph{\header{From}}
\label{sec:general:uac:header:from}

The \header{From} header field indicates the logical identity of the
initiator of the request, possibly the user's address-of-record.  Like
the \header{To} header field, it contains a URI and optionally a display
name.  It is used by SIP elements to determine which processing rules to
apply to a request (for example, automatic call rejection).  As such, it
is very important that the \header{From} URI not contain IP addresses or
the FQDN of the host on which the UA is running, since these are not
logical names.

The \header{From} header field allows for a display name.  A UAC
{\SHOULD} use the display name ``Anonymous'', along with a syntactically
correct, but otherwise meaningless URI (like
sip:thisis@anonymous.invalid), if the identity of the client is to
remain hidden.

Usually the value that populates the \header{From} header field in
requests generated by a particular UA is pre-provisioned by the user or
by the administrators of the user's local domain.  If a particular UA is
used by multiple users, it might have switchable profiles that include a
URI corresponding to the identity of the profiled user.  Recipients of
requests can authenticate the originator of a request in order to
ascertain that they are who their \header{From} header field claims they
are (see Section~\ref{sec:security:auth} for more on authentication).

The \header{From} field {\MUST} contain a new ``\header{tag}''
parameter, chosen by the UAC.  See Section~\ref{sec:common-message:tags}
for details on choosing a tag.

For further information on the \header{From} header field, see
Section~\ref{sec:From}. Examples:

\begin{changebar}
\begin{verbatim}
  From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
  From: sip:+12125551212@phone2net.com;tag=887s
  From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
\end{verbatim}
\end{changebar}

\paragraph{\header{Call-ID}}
\label{sec:general:uac:header:Call-ID}

The \header{Call-ID} header field acts as a unique identifier to
group together a series of messages.  It {\MUST} be the same for all
requests and responses sent by either UA in a dialog.  It {\SHOULD} be
the same in each registration from a UA.

In a new request created by a UAC outside of any dialog, the
\header{Call-ID} header field {\MUST} be selected by the UAC as a globally
unique identifier over space and time unless overridden by method-specific 
behavior.  All SIP UAs must have a means to guarantee
that the \header{Call-ID} header fields they produce will not be inadvertently
generated by any other UA.  Note that when requests are retried
after certain failure responses that solicit an amendment to a request
(for example, a challenge for authentication), these retried requests
are not considered new requests, and therefore do not need new
\header{Call-ID} header fields; see Section~\ref {sec:general:resp-proc:4xx}. 

Use of cryptographically random identifiers 
(RFC~1750~\citenorm{rfc1750}) in the generation of Call-IDs is {\RECOMMENDED}. 
Implementations {\MAY} use the form ``localid@host''.  \header{Call-IDs}
are case-sensitive and are simply compared byte-by-byte. 
\motivation{Using cryptographically random identifiers provides some
protection against session hijacking and reduces the likelihood of
unintentional \header{Call-ID} collisions.}

No provisioning or human interface is required for the selection of the
\header{Call-ID} header field value for a request.

For further information on the \header{Call-ID} header field, see 
Section~\ref{sec:Call-ID}.

Example:

\begin{verbatim}
  Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
\end{verbatim}

\paragraph{\header{CSeq}}
\label{sec:general:uac:header:CSeq}

The \header{CSeq} header field serves as a way to identify and order
transactions.  It consists of a sequence number and a method. The
method {\MUST} match that of the request. For non-{\REGISTER} requests outside of a
dialog, the sequence number value is arbitrary. The sequence number value {\MUST} be
expressible as a 32-bit unsigned integer and {\MUST} be less than
2**31. As long as it follows the above guidelines, a client may use
any mechanism it would like to select \header{CSeq} header field
values.

Section~\ref{sec:dialog:uac:generate} discusses construction of
the \header{CSeq} for requests within a dialog.

Example:

\begin{verbatim}
  CSeq: 4711 INVITE
\end{verbatim}

\paragraph{\header{Max-Forwards}}
\label{sec:general:uac:header:max-forwards}

The \header{Max-Forwards} header field serves to limit the number of hops a
request can transit on the way to its destination.  It consists of an
integer that is decremented by one at each hop.  If the Max-Forwards
value reaches 0 before the request reaches its destination, it will be
rejected with a 483(Too~Many~Hops) error response.


A UAC {\MUST} insert a \header{Max-Forwards} header field into each
request it originates with a value which {\SHOULD} be 70. This number was
chosen to be sufficiently large to guarantee that a request would not be
dropped in any SIP network when there were no loops, but not so large as to
consume proxy resources when a loop does occur. Lower values should be used
with caution and only in networks where topologies are known by the UA. 


\paragraph{\header{Via}}
\label{sec:general:uac:header:via}

The \header{Via} header field indicates the transport used for the
transaction and identifies the location where the response is to be
sent. 
\begin{changebar}
A \header{Via} header field value is added only after the transport that will be
used to reach the next hop has been selected (which may involve the usage
of the procedures in~\citenorm{draft-ietf-sip-srv}).
\end{changebar}

When the UAC creates a request, it {\MUST} insert a \header{Via} into
that request.  The protocol name and protocol version in the 
header field {\MUST} be SIP and
2.0, respectively.  The \header{Via} header field value {\MUST} contain a
branch parameter.  This parameter is used to identify the
transaction created by that request.  This parameter is used by both the
client and the server.

\begin{changebar}
The \header{branch} parameter value {\MUST} be unique across space and time for
all requests sent by the UA.  The exceptions to this rule are {\CANCEL}
and {\ACK} for non-2xx responses.  
As discussed below, a {\CANCEL} request will have the same value of the
branch parameter as the request it cancels. As discussed in 
Section~\ref{sec:transactions:client:invite:ack}, an {\ACK} for a non-2xx response
will also have the same branch ID as the {\INVITE} whose response it
acknowledges.
\end{changebar}

\motivation{The uniqueness property of the branch ID parameter, to
facilitate its use as a transaction ID, was not part of RFC~2543}

The branch ID inserted by an element compliant with this specification
{\MUST} always begin with the characters ``z9hG4bK''.  These 7
characters are used as a magic cookie (7 is deemed sufficient to ensure
that an older RFC~2543 implementation would not pick such a value), so
that servers receiving the request can determine that the branch ID was
constructed in the fashion described by this specification (that is,
globally unique).  Beyond this requirement, the precise format of the
\header{branch} token is implementation-defined. 

The \header{Via} header \header{maddr}, \header{ttl}, and
\header{sent-by} components will be set when the request is processed by
the transport layer (Section~\ref{sec:transport}).

\header{Via} processing for proxies is described in 
Section~\ref{sec:proxy-request-processing}
Item~\ref{sec:proxy-request-processing-via} 
and
Section~\ref{sec:proxy-response-processing}
Item~\ref{sec:proxy-response-processing-via}. 

\paragraph{\header{Contact}}
\label{sec:general:uac:header:contact}

The \header{Contact} header field provides a SIP URI that can be used to
contact that specific instance of the UA for subsequent
requests.  The \header{Contact} header field {\MUST} be present  
\begin{changebar}
and contain exactly one SIP or SIPS URI
\end{changebar}
in any request
that can result in the establishment of a dialog.  For the methods
defined in this specification, that includes only the {\INVITE} request. 
 For these requests, the scope of the \header{Contact} is global.
That is, the \header{Contact} header field value contains the URI at which the UA
would like to receive requests, and this URI {\MUST} be valid even if 
used in subsequent requests outside of any dialogs.  

\begin{changebar} If the \header{Request-URI} or top \header{Route} header field value contains a SIPS URI, the
\header{Contact} header field {\MUST} contain a SIPS URI as well.
\end{changebar}

For further information on the \header{Contact} header field, see 
Section~\ref{sec:Contact}.

\paragraph{\header{Supported} and \header{Require}}
\label{sec:general:uac:header:supported}


If the UAC supports extensions to SIP that can be applied by the
server to the response, the UAC {\SHOULD} include a \header{Supported}
header field in the request listing the option tags 
(Section~\ref{sec:option_tags}) for those
extensions. 

The option tags listed {\MUST} only refer to extensions defined in
standards-track RFCs.  This is to prevent servers from insisting that
clients implement non-standard, vendor-defined features in order to
receive service.  Extensions defined by experimental and informational
RFCs are explicitly excluded from usage with the \header{Supported}
header field in a request, since they too are often used to document
vendor-defined extensions.

If the UAC wishes to insist that a UAS understand an extension that the
UAC will apply to the request in order to process the request, it
{\MUST} insert a \header{Require} header field into the request listing the
option tag for that extension.  If the UAC wishes to apply an extension
to the request and insist that any proxies that are traversed understand
that extension, it {\MUST} insert a \header{Proxy-Require} header field into
the request listing the option tag for that extension.

\begin{changebar}
As with the \header{Supported} header field, the option tags in the
\header{Require} and \header{Proxy-Require} header fields {\MUST} only refer to extensions defined in standards-track RFCs.
\end{changebar}

\paragraph{Additional Message Components}
\label{sec:general:uac:steps}

After a new request has been created, and the header fields described above
have been properly constructed, any additional optional header fields are
added, as are any header fields specific to the method. 

SIP requests {\MAY} contain a MIME-encoded message-body.  Regardless of
the type of body that a request contains, certain header fields must be
formulated to characterize the contents of the body.  For further
information on these header fields, see 
\begin{changebar}
Sections~\ref{sec:Content-Disposition} 
through~\ref{sec:Content-Type}. 
\end{changebar}

\subsubsection{Sending the Request}
\label{sec:general:sending}


The destination for the request is then computed. Unless there is
local policy specifying otherwise, then the destination {\MUST} be
determined by applying the DNS procedures described 
in~\citenorm{draft-ietf-sip-srv} as follows. 
If the first element in the route set indicated a strict router
(resulting in forming the request as described in
Section~\ref{sec:dialog:uac:generate}),
the procedures {\MUST} be applied to the 
\header{Request-URI} of the request.
Otherwise, the procedures are applied 
to the first \header{Route} header field
value in the request (if one exists), or to the request's
\header{Request-URI} if there is no \header{Route} header
field present. These procedures yield an ordered set of address, port, and
transports to attempt. \begin{changebar} Independent of which URI
is used as input to the procedures of \cite{draft-ietf-sip-srv},
if the \header{Request-URI} specifies a SIPS resource, the UAC {\MUST}
follow the procedures of \cite{draft-ietf-sip-srv} as if the input URI were
a SIPS URI. \end{changebar}

Local policy {\MAY} specify an alternate set of destinations to
attempt. \begin{changebar} If the \header{Request-URI} contains a SIPS URI,
any alternate destinations {\MUST} be contacted with TLS. Beyond that, 
\end{changebar} there are no restrictions on the alternate destinations if the
request contains no
\header{Route} header field. This provides a simple alternative to a
pre-existing route set as a way to specify an outbound proxy. However,
that approach for configuring an outbound proxy is {\NOTRECOMMENDED}; a
pre-existing route set with a single URI {\SHOULD} be used instead. If
\begin{changebar}
the request contains a \header{Route} header field, the request {\SHOULD} be sent
to the locations derived from its topmost value, but {\MAY} be
sent to any server that the UA is certain will honor the
\header{Route} and \header{Request-URI} policies specified in this
document (as opposed to those in RFC~2543). In particular, a UAC configured
with an outbound proxy {\SHOULD} attempt to send the request to the location
indicated in the first \header{Route} header field value instead of adopting 
the policy of sending all messages to the outbound proxy.

\motivation{
This ensures that outbound proxies that do not add \header{Record-Route}
header field values will drop out of the path of subsequent requests. It allows
endpoints that cannot resolve the first \header{Route} URI to delegate that
task to an outbound proxy.
}

\end{changebar}

The UAC {\SHOULD} follow the procedures defined 
in~\citenorm{draft-ietf-sip-srv} for stateful elements, trying each address
until a server is contacted.  Each try constitutes a new transaction,
and therefore each carries a different topmost \header{Via} header field value with a new
branch parameter.  Furthermore, the transport value in the
\header{Via} header field is set to whatever transport was determined for
the target server. 

 
\subsubsection{Processing Responses}
\label{sec:general:resp-proc}

Responses are first processed by the transport layer and then passed up
to the transaction layer.  The transaction layer performs its processing
and then passes the response up to the TU.  
The majority of response processing in
the TU is method specific.  However, there are some general behaviors
independent of the method.

\paragraph{Transaction Layer Errors}

\begin{changebar}
In some cases, the response returned by the transaction layer will not
be a SIP message, but rather a transaction layer error.  When a timeout 
error is received from the transaction layer, it {\MUST} be treated as if a
408 (Request Timeout) status code has been received. If a fatal transport
error is reported by the transport layer (generally, due to fatal
ICMP errors in UDP or connection failures in TCP), the condition
{\MUST} be treated as a 503 (Service Unavailable) status code. 
\end{changebar}

\paragraph{Unrecognized Responses}
\begin{changebar}
A UAC {\MUST} treat any final response it does not recognize as being
equivalent to the x00 response code of that class, and {\MUST} be able
to process the x00 response code for all classes.  For example, if a UAC
receives an unrecognized response code of 431, it can safely assume that
there was something wrong with its request and treat the response as if
it had received a 400 (Bad Request) response code. A UAC {\MUST} treat any provisional response different than 100 that it does not recognize as 183 (Session Progress). A UAC {\MUST} be able to process 100 and 183 responses.
\end{changebar}

\paragraph{Vias}

\begin{changebar}
If more than one \header{Via} header field value is present in a response, the
UAC {\SHOULD} discard the message.  \motivation{The presence of
additional \header{Via} header field values that precede the originator of the
request suggests that the message was misrouted or possibly corrupted.}
\end{changebar}

\paragraph{Processing 3xx Responses}
\label{sec:ua:processing-3xx}

Upon receipt of a redirection response (for example, a 301 response
status code), clients {\SHOULD} use the URI(s) in the \header{Contact}
header field to formulate one or more new requests based on the
redirected request. 
\begin{changebar} This process is similar to that of a proxy
recursing on a 3xx class response as detailed in 
Sections~\ref{sec:proxy-determine-targets}
and~\ref{sec:proxy-request-forwarding}. 
A client starts with an initial target set containing exactly
one URI, the \header{Request-URI} of the original request.
If a client wishes to formulate new requests based on a 3xx class
response to that request, it places the URIs to try into
the target set.  Subject to the restrictions in this specification,
a client can choose which \header{Contact} URIs it places into
the target set.  As with proxy recursion, a client processing 
3xx class responses {\MUSTNOT} add any given URI to the target set 
more than once.
If the original request had 
a SIPS URI in the \header{Request-URI}, the client {\MAY} choose to
recurse to a non-SIPS URI, but {\SHOULD} inform the user of the redirection
to an insecure URI. 

\motivation{Any new request may receive 3xx responses themselves
containing the original URI as a contact. Two locations can be
configured to redirect to each other. Placing any given URI in the
target set only once prevents infinite redirection loops.}

As the target set grows, the client {\MAY} generate new requests
to the URIs in any order. A common mechanism is to order the set
by the ``\header{q}'' parameter value from the \header{Contact}
header field value. Requests to the URIs {\MAY} be generated
serially or in parallel.  One approach is to process groups 
of decreasing q-values serially and process the URIs in each 
q-value group in parallel. Another is to perform only serial
processing in decreasing q-value order, arbitrarily choosing
between contacts of equal q-value.

If contacting an address in the list results in a failure, as defined in
the next paragraph, the element moves to the next address in the list,
until the list is exhausted.  If the list is exhausted, then the request
has failed.

Failures {\SHOULD} be detected through failure response codes (codes
greater than 399); for network errors the client transaction will report
any transport layer failures to the transaction user. Note that some 
response codes (detailed in~\ref{sec:general:resp-proc:4xx}) indicate that 
the request can be retried; requests that are reattempted should not be
considered failures.

When a failure for a particular contact address is received, the client
{\SHOULD} try the next contact address.  This will involve creating a
new client transaction to deliver a new request.

In order to create a request based on a contact address in a 3xx
response, a UAC {\MUST} copy the entire URI from the target set
into the \header{Request-URI}, except for the
``\header{method-param}'' and ``\header{header}'' URI parameters (see
Section~\ref{sec:sip-uri-components} for a definition of these
parameters).  It uses the ``\header{header}'' parameters to create
header field values for the new request, overwriting header field values 
associated with the
redirected request in accordance with the guidelines in
Section~\ref{sec:uri-forming-requests}. 
\end{changebar}

Note that in some instances, header fields that have been communicated in the
contact address may instead append to existing request header fields in the
original redirected request.  As a general rule, if the header field can
accept a comma-separated list of values, then the new header field value
{\MAY} be appended to any existing values in the original redirected
request.  If the header field does not accept multiple values, the value in
the original redirected request {\MAY} be overwritten by the header field
value communicated in the contact address.  For example, if a contact
address is returned with the following value:

\begin{verbatim}
sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>
\end{verbatim}

Then any \header{Subject} header field in the original redirected request is
overwritten, but the HTTP URL is merely appended to any existing
\header{Call-Info} header field values.

It is {\RECOMMENDED} that the UAC reuse the same \header{To},
\header{From}, and \header{Call-ID} used in the original redirected
request, but the UAC {\MAY} also choose to update the
\header{Call-ID} header field value for new requests, for example.

Finally, once the new request has been constructed, it is sent using a
new client transaction, and therefore {\MUST} have a new branch ID in
the top \header{Via} field as discussed in 
Section~\ref{sec:general:uac:header:via}. 

In all other respects, requests sent upon receipt of a redirect response 
{\SHOULD} re-use the header fields and bodies of the original request.

In some instances, \header{Contact} header field values may be cached at UAC
temporarily or permanently depending on the status code received and the
presence of an expiration interval; see
Sections~\ref{sec:response-codes:301} and~\ref{sec:response-codes:302}.

\paragraph{Processing 4xx Responses}
\label{sec:general:resp-proc:4xx}

Certain 4xx response codes require specific UA processing, independent
of the method.

If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response
is received, the UAC {\SHOULD} follow the authorization procedures of
Section~\ref{sec:security:auth:u2u} and 
Section~\ref{sec:security:auth:p2u} to retry the request with credentials.

If a 413 (Request Entity Too Large) response is received 
(Section~\ref{sec:response-codes:413}), the request contained a body that was
longer than the UAS was willing to accept.  If possible, the UAC
{\SHOULD} retry the request, either omitting the body or using one of a
smaller length.

If a 415 (Unsupported Media Type) response is received 
(Section~\ref{sec:response-codes:415}), the request contained media types not
supported by the UAS.  The UAC {\SHOULD} retry sending the request, this
time only using content with types listed in the \header{Accept} header field
in the response, with encodings listed in the \header{Accept-Encoding}
header field in the response, and with languages listed in the
\header{Accept-Language} in the response.

If a 416 (Unsupported URI Scheme) response is received 
(Section~\ref{sec:response-codes:416}), the \header{Request-URI} used a URI
scheme not supported by the server. The client {\SHOULD} retry the
request, this time, using a SIP URI.

If a 420 (Bad Extension) response is received 
(Section~\ref{sec:response-codes:420}), the request contained a \header{Require}
or \header{Proxy-Require} header field listing an option-tag for a feature not
supported by a proxy or UAS.  The UAC {\SHOULD} retry the request, this
time omitting any extensions listed in the \header{Unsupported} header
field in the response. 

In all of the above cases, the request is retried by creating a new
request with the appropriate modifications.  This new request {\SHOULD}
have the same value of the \header{Call-ID}, \header{To}, and
\header{From} of the previous request, but the \header{CSeq} should
contain a new sequence number that is one higher than the previous.

With other 4xx responses, including those yet to be defined, a retry may
or may not be possible depending on the method and the use case.

\subsection{UAS Behavior}
\label{sec:general:req-process}

When a request outside of a dialog is processed by a UAS, there is a set
of processing rules that are followed, independent of the method. 
Section~\ref{sec:dialog} gives guidance on how a UAS can tell whether a
request is inside or outside of a dialog.

Note that request processing is atomic.  If a request is accepted, all
state changes associated with it {\MUST} be performed.  If it is
rejected, all state changes {\MUSTNOT} be performed.

UASs {\SHOULD} process the requests in the order of the steps that follow
in this section (that is, starting with authentication, then inspecting the
method, the header fields, and so on throughout the remainder of this section).

\subsubsection{Method Inspection}
\label{sec:general:req-process:method}

\begin{changebar}
Once a request is authenticated (or authentication is skipped), the
UAS {\MUST} inspect the method of the request.  If the UAS recognizes
but does not support the method of a request, it {\MUST} generate a 
405 (Method Not Allowed) response.  Procedures for generating responses 
are described in Section~\ref{sec:general:serv-resp}.  The UAS {\MUST} 
also add an \header{Allow} header field to the 405 (Method Not Allowed) 
response.  The \header{Allow} header field {\MUST} list the set of 
methods supported by the UAS generating the message.  The \header{Allow} 
header field is presented in Section~\ref{sec:Allow}.
\end{changebar}

If the method is one supported by the server, processing continues.

\subsubsection{Header Inspection}
\label{sec:general:req-process:header}

If a UAS does not understand a header field in a request (that is, the
header field is not defined in this specification or in any supported
extension), the server {\MUST} ignore that header field and continue
processing the message.  A UAS {\SHOULD} ignore any malformed header fields
that are not necessary for processing requests. 

\paragraph{\header{To} and \header{Request-URI}}

The \header{To} header field identifies the original recipient of the
request designated by the user identified in the \header{From} field. 
The original recipient may or may not be the UAS processing the request,
due to call forwarding or other proxy operations.  A UAS {\MAY} apply
any policy it wishes to determine whether to accept requests when
the \header{To} header field is not the identity of the UAS.  However, it is
{\RECOMMENDED} that a UAS accept requests even if they do not recognize
the URI scheme (for example, a \texttt{tel:} URI) in the \header{To}
header field, or if the \header{To} header field does not address a known or
current user of this UAS.  If, on the other hand, the UAS decides to
reject the request, it {\SHOULD} generate a response with a 403
(Forbidden) status code and pass it to the server transaction for
transmission.

However, the \header{Request-URI} identifies the UAS that is to process
the request.  If the \header{Request-URI} uses a scheme not supported by
the UAS, it {\SHOULD} reject the request with a 416 (Unsupported URI
Scheme) response.  If the \header{Request-URI} does not identify an
address that the UAS is willing to accept requests for, it {\SHOULD}
reject the request with a 404 (Not Found) response.  Typically, a UA
that uses the {\REGISTER} method to bind its address-of-record to a
specific contact address will see requests whose \header{Request-URI}
equals that contact address.  Other potential sources of received
Request-URIs include the \header{Contact} header fields of requests and
responses sent by the UA that establish or refresh dialogs.

\paragraph{Merged Requests}
\label{sec:general:req-process:header:merge}

\begin{changebar}
If the request has no tag in the \header{To} header field, the 
UAS core {\MUST}
check the request against ongoing
transactions.  If the \header{To} tag, \header{From} tag, \header{Call-ID},
\header{CSeq} exactly match (including tags) those associated with
an ongoing transaction,
but the branch-ID in the topmost \header{Via} does not match, 
the UAS core {\SHOULD} generate a
\end{changebar}
482 (Loop Detected) response and pass it to the server transaction. 
\motivation{The same request has arrived at the UAS more than once,
following different paths, most likely due to forking.  The UAS
processes the first such request received and responds with a 482 (Loop
Detected) to the rest of them.}

\paragraph{\header{Require}}

Assuming the UAS decides that it is the proper element to process the
request, it examines the \header{Require} header field, if present.

The \header{Require} header field is used by a UAC to tell a UAS
about SIP extensions that the UAC expects the UAS to support in order to
process the request properly.  Its format is described in 
Section~\ref{sec:Require}.  If a UAS does not understand an option-tag listed in
a \header{Require} header field, it {\MUST} respond by generating a
response with status code 420 (Bad Extension).  The UAS {\MUST} add an
\header{Unsupported} header field, and list in it those options it does
not understand amongst those in the \header{Require} header field of the
request.  

Note that \header{Require} and \header{Proxy-Require} {\MUSTNOT} be used
in a SIP {\CANCEL} request, or in an {\ACK} request sent for a non-2xx
response.  These header fields 
\begin{changebar}
{\MUST}
\end{changebar}
be ignored if they are present in these
requests.

An {\ACK} request for a 2xx response {\MUST} contain only those
\header{Require} and \header{Proxy-Require} values that were present in
the initial request.


Example:
\begin{verbatim}
UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0
            Require: 100rel


UAS->UAC:   SIP/2.0 420 Bad Extension
            Unsupported: 100rel
\end{verbatim}

\motivation{This behavior ensures that the client-server interaction
will proceed without delay when all options are understood by both
sides, and only slow down if options are not understood (as in the
example above).  For a well-matched client-server pair, the interaction
proceeds quickly, saving a round-trip often required by negotiation
mechanisms.  In addition, it also removes ambiguity when the client
requires features that the server does not understand.  Some features,
such as call handling fields, are only of interest to end systems.}

\subsubsection{Content Processing}
\label{sec:general:req-process:content}

Assuming the UAS understands any extensions required by the client, the
UAS examines the body of the message, and the header fields that describe it. 
If there are any bodies whose type (indicated by the
\header{Content-Type}), language (indicated by the
\header{Content-Language}) or encoding (indicated by the
\header{Content-Encoding}) are not understood, and that body part is not
optional (as indicated by the \header{Content-Disposition} header field), the
UAS {\MUST} reject the request with a 415 (Unsupported Media Type)
response.  The response {\MUST} contain an \header{Accept} header field
listing the types of all bodies it understands, in the event the request
contained bodies of types not supported by the UAS.  If the request
contained content encodings not understood by the UAS, the response
{\MUST} contain an \header{Accept-Encoding} header field listing the encodings
understood by the UAS.  If the request contained content with languages
not understood by the UAS, the response {\MUST} contain an
\header{Accept-Language} header field indicating the languages understood by
the UAS.  Beyond these checks, body handling depends on the method and
type.  For further information on the processing of content-specific
header fields, see Section~\ref{sec:message-bodies} as well as
Section~\ref{sec:Content-Disposition} through~\ref{sec:Content-Type}.

\subsubsection{Applying Extensions}
\label{sec:general:req-process:ext}

A UAS that wishes to apply some extension when generating the response
{\MUSTNOT} do so unless support for that extension is indicated in the
\header{Supported} header field in the request.  If the desired extension is
not supported, the server {\SHOULD} rely only on baseline SIP and any
other extensions supported by the client.  
In rare circumstances, where the server
cannot process the request without the extension, the server {\MAY} send
a 421 (Extension Required) response.  This response indicates that the
proper response cannot be generated without support of a specific
extension.  The needed extension(s) {\MUST} be included in a
\header{Require} header field in the response.  This behavior is
{\NOTRECOMMENDED}, as it will generally break interoperability.

Any extensions applied to a non-421 response {\MUST} be listed in a
\header{Require} header field included in the response.  Of course, the server
{\MUSTNOT} apply extensions not listed in the \header{Supported} header
field in the request.  As a result of this, the \header{Require} header field in a
response will only ever contain option tags defined in standards-track
RFCs.

\subsubsection{Processing the Request}
\label{sec:general:req-process:req}

Assuming all of the checks in the previous subsections are passed, the
UAS processing becomes method-specific.  Section~\ref{sec:reg} covers
the {\REGISTER} request, section~\ref{sec:query-for-capabilities} covers
the {\OPTIONS} request, section~\ref{sec:initiate} covers the {\INVITE}
request, and section~\ref{sec:terminate} covers the {\BYE} request.

\subsubsection{Generating the Response}
\label{sec:general:serv-resp}

\begin{changebar}
When a UAS wishes to construct a response to a request, it follows the
general procedures detailed in the following subsections. Additional
behaviors specific to the response code in question, which are not 
detailed in this section, may also be required.

Once all procedures associated with the creation of a response have 
been completed, the UAS hands the response back to the server
transaction from which it received the request.
\end{changebar}

\paragraph{Sending a Provisional Response}

One largely non-method-specific guideline for the generation of
responses is that UASs {\SHOULDNOT} issue a provisional response for a
non-{\INVITE} request.  Rather, UASs {\SHOULD} generate a final response
to a non-{\INVITE} request as soon as possible.

When a 100 (Trying) response is generated, any \header{Timestamp} header
field present in the request {\MUST} be copied into this 100 (Trying)
response.  If there is a delay in generating the response,
the UAS {\SHOULD} add a delay value into the \header{Timestamp} value in
the response. This value {\MUST} contain the difference between time of 
sending of the response and receipt of the request, measured in seconds. 


\paragraph{Headers and Tags}

The \header{From} field of the response {\MUST} equal the \header{From}
header field of the request.  The \header{Call-ID} header field of the response
{\MUST} equal the \header{Call-ID} header field of the request.  The
\header{CSeq} header field of the response {\MUST} equal the \header{CSeq}
field of the request.  The \header{Via} header field values in the response 
{\MUST} equal the \header{Via} header field values in the request and 
{\MUST} maintain the same ordering. 

If a request contained a \header{To} tag in the request, the \header{To}
header field in the response {\MUST} equal that of the request.  However, if
the \header{To} header field in the request did not contain a tag, the URI in
the \header{To} header field in the response {\MUST} equal the URI in the
\header{To} header field; additionally, the UAS {\MUST} add a
tag to the \header{To} header field in the response (with the exception of the
100 (Trying) response, in which a tag {\MAY} be present).  This serves
to identify the UAS that is responding, possibly resulting in a
component of a dialog ID.  The same tag {\MUST} be used for all
responses to that request, both final and provisional (again excepting
the 100 (Trying)).  Procedures for generation of tags are defined in
Section~\ref{sec:common-message:tags}.

\subsubsection{Stateless UAS Behavior}
\label{sec:general:serv-stateless}

A stateless UAS is a UAS that does not maintain transaction state.  It
replies to requests normally, but discards any state that would
ordinarily be retained by a UAS after a response has been sent.  If a
stateless UAS receives a retransmission of a request, it regenerates the
response and resends it, just as if it were replying to the first
instance of the request.  Stateless UASs do not use a transaction layer;
they receive requests directly from the transport layer and send
responses directly to the transport layer.

The stateless UAS role is needed primarily to handle unauthenticated
requests for which a challenge response is issued.  If unauthenticated
requests were handled statefully, then malicious floods of
unauthenticated requests could create massive amounts of transaction
state that might slow or completely halt call processing in a UAS,
effectively creating a denial of service condition; for more information
see Section~\ref{sec:security:threats:dos}.

The most important behaviors of a stateless UAS are the following:

\begin{itemize}
\item A stateless UAS {\MUSTNOT} send provisional (1xx) responses.
\item A stateless UAS {\MUSTNOT} retransmit responses.
\item A stateless UAS {\MUST} ignore {\ACK} requests.
\item A stateless UAS {\MUST} ignore {\CANCEL} requests.
\item \header{To} header tags {\MUST} be generated for responses 
in a stateless manner - in a manner that will generate the same tag for
the same request consistently.
For information on tag construction see Section~\ref{sec:common-message:tags}.
\end{itemize}

In all other respects, a stateless UAS behaves in the same manner as a 
stateful UAS. A UAS can operate in either a stateful or stateless mode for
each new request.

\subsection{Redirect Servers}
\label{sec:general:redirect}

In some architectures it may be desirable to reduce the processing load
on proxy servers that are responsible for routing requests, and improve
signaling path robustness, by relying on redirection.  Redirection
allows servers to push routing information for a request back in a
response to the client, thereby taking themselves out of the loop of
further messaging for this transaction while still aiding in locating
the target of the request.  When the originator of the request receives
the redirection, it will send a new request based on the URI(s) it has
received.  By propagating URIs from the core of the network to its
edges, redirection allows for considerable network scalability.

A redirect server is logically constituted of a server transaction layer
and a transaction user that has access to a location service of some
kind (see Section~\ref{sec:reg} for more on registrars and location
services).  This location service is effectively a database containing
mappings between a single URI and a set of one or more alternative
locations at which the target of that URI can be found.

A redirect server does not issue any SIP requests of its own.  After
receiving a request other than {\CANCEL}, the server either refuses 
the request or gathers the list of alternative locations from the 
location service and returns a
final response of class 3xx.  For well-formed
{\CANCEL} requests, it {\SHOULD} return a 2xx response.  This response
ends the SIP transaction.  The redirect server maintains transaction
state for an entire SIP transaction.  It is the responsibility of
clients to detect forwarding loops between redirect servers.

When a redirect server returns a 3xx response to a request, it populates
the list of (one or more) alternative locations into the \header{Contact}
header field.  An ``\header{expires}'' parameter to the \header{Contact}
header field values may also be supplied to indicate the lifetime of the
\header{Contact} data. 

The \header{Contact} header field contains URIs giving the new locations
or user names to try, or may simply specify additional transport
parameters.  A 301 (Moved Permanently) or 302 (Moved Temporarily)
response may also give the same location and username that was targeted
by the initial request but specify additional transport parameters such
as a different server or multicast address to try, or a change of SIP
transport from UDP to TCP or vice versa. 

However, redirect servers {\MUSTNOT} redirect a request to a URI equal
to the one in the \header{Request-URI}; instead, provided that the URI
does not point to itself, the redirect server {\SHOULD} proxy the
request to the destination URI.  \motivation{If a client is using an
outbound proxy, and that proxy actually redirects requests, a potential
arises for infinite redirection loops.}

Note that a \header{Contact} header field value {\MAY} also refer to a
different resource than the one originally called.  For example, a SIP
call connected to PSTN gateway may need to deliver a special
informational announcement such as ``The number you have dialed has been
changed.''

A \header{Contact} response header field can contain any suitable URI
indicating where the called party can be reached, not limited to SIP
URIs.  For example, it could contain URIs for phones, fax, or
\header{irc} (if they were defined) or a \header{mailto:} 
(RFC~2368~\citenonnorm{rfc2368}) URL. \begin{changebar} Section \ref{sec:security:limits:sips}
discusses implications and limitations of redirecting a SIPS URI to a
non-SIPS URI. \end{changebar}

The ``\header{expires}'' parameter of a \header{Contact} header field
value indicates how long the URI is valid.  The value of the parameter is a
number indicating seconds.  If this parameter is not provided, the value
of the \header{Expires} header field determines how long the URI is
valid.  Malformed values {\SHOULD} be treated as equivalent to 3600. 

\begin{changebar}
\motivation{This provides a modest level of backwards compatibility with 
RFC~2543, which allowed absolute times in this header field. If an absolute time is
received, it will be treated as malformed, and then default to 3600.}
\end{changebar}

Redirect servers {\MUST} ignore features that are not understood
(including unrecognized header fields, any unknown option tags in
\header{Require}, or even
method names) and proceed with the redirection of the request in
question.  

% [JFP] - Not sure whether this should be here or not.
%
% If a particular extension requires that intermediate devices
% support it, the extension {\MUST} be tagged in the
% \header{Proxy-Require} field as well (see
% Section~\ref{sec:Proxy-Require}).
