\section{Behavior of SIP Elements that Receive Prioritized Requests}
\label{sec:ua-proxy}

\subsection{General Rules}

All user agent servers and proxy servers that receive SIP requests share
certain common behavior, which we describe below. Behavior that is
specific to user agent servers is covered in Section~\ref{sec:uas},
while Section~\ref{sec:proxy} deals with proxy behavior.

A SIP element supporting this specification {\MUST} be able to interpret
the \header{Resource-Priority} header field in {\INVITE}, {\MESSAGE}
\citenorm{rfc3428}, {\UPDATE} \citenorm{rfc3311}, {\SUBSCRIBE}
\citenorm{rfc3265} and {\NOTIFY} \citenorm{rfc3265} requests.  It {\MAY}
ignore the header field in other requests unless the request definition
defines behavior for the particular method. 

If a request contains multiple valid namespace/priority values, it is up
to local policy to determine how the request is treated.

\subsection{Error Conditions}

\subsection{Known Namespace and Priority Value}

Two error conditions can occur if a request reaches an element that
supports the namespace and resource priority. Elements receiving
requests with namespaces or priority values that they do not understand
act according to the rules in the next section.

\begin{description}
\item[Insufficient authorization:] If the element receives a request
with a namespace and priority value it recognizes, but the originator is
not authorized for that level of service, the element {\MUST} return a
403 (Forbidden) response. 

\item[Insufficient resources:] If there are insufficient resources at an
element for a given priority, a request might be delayed or refused,
depending on local policy or the definition of the namespace.  If it is
refused, the element returns a 503 (Service Unavailable) response.  The
response {\MAY} also include a \header{Warning} header with warning code
370 (Insufficient Bandwidth) if the request failed due to insufficient
capacity for the media streams, rather than insufficient signaling
capacity.

The 503 (Service Unavailable) response provides sufficient indication to
the originator to re-attempt with a higher appropriate resource
priority or to add a resource priority indication, if authorized. 

\end{description}

\subsection{Handling Unknown Namespaces and Priority Values}

When handling requests with unknown namespsaces or priority values,
elements can operate in two modes, ``strict'' and ``loose''.  If the
request includes a \header{Require} header field with the
\header{Resource-Priority} option tag, a UAS {\MUST} follow the strict
rules, otherwise UAS and proxies may choose either mode according to
local policy.

Following standard behavior (Section 8.2.2.3 of \citenorm{rfc3261}), a
UAS {\MUST} then reject the request with response code 420 (Bad
Extension) if it does not understand the resource priority mechanism. 

\motivation{For example, a gateway that is unaware of a resource
priority namespace might accept a request at non-elevated priority, but
then the request could later be preempted by other requests.  Also, use
of the \header{Require} restriction ensures that in parallel forking,
only branches that support the resource priority mechanism succeed.}

The use of the \header{Resource-Priority} option tag with
\header{Proxy-Require} is {\NOTRECOMMENDED}.

\subsubsection{Strict Mode}

In strict mode, an element that receives a request with a
\header{Resource-Priority} header field containing one or more namespace
or priority values that it does not know rejects the request with status
code 417 (Unknown Resource-Priority) and includes a
\header{Accept-Resource-Priority} header field enumerating all the
resource values that the server is willing to process.  Note that the
user may not be authorized to use all of these resource values.

\motivation{Strict mode is particularly useful for operational testing
of systems supporting resource priority, as otherwise it might be
difficult to detect under non-overload conditions whether an element
supports the functionality or not.}

\subsubsection{Loose Mode}

In loose mode, unknown priority values or namespaces are ignored; the
request is treated as if these values were not included.  If there are
no valid priority values or namespaces, the request is treated as if it
had no \header{Resource-Priority} header field.  Thus, no 417 (Unknown
Resource-Priority) is generated.

\subsection{User Agent Client Behavior}
\label{sec:uac}

SIP UACs supporting this specification {\MUST} be able to generate the
\header{Resource-Priority} header field for requests that require
elevated resource access priority.

If the request is returned with 417 (Unknown Resource-Priority), the UAC
{\MAY} retry the request with a different namespace value, drawing from
the values returned by the \header{Accept-Resource-Priority} header
field in the response.

\subsection{User Agent Server Behavior}
\label{sec:uas}

The {\OPTIONS} request can be used to determine if a UAS supports the
mechanism. A compliant implementation {\SHOULD} return a
\header{Accept-Resource-Priority} header field in {\OPTIONS} responses
enumerating all valid resource values. An implementation {\MAY} reveal
this capability only to authorized UACs.

If the UAS understands the resource value, but refuses to honor the
request with elevated priority for this particular user, it returns the
403 (Forbidden) response code.  It {\MAY} include the list of resource
values that the user is allowed to use in the
\header{Accept-Resource-Priority} response header field.

\motivation{The lookup of the authorized values may take significant
resources since it may involve an AAA interaction.  Thus, it seems
imprudent to require that the list is customized to the user.  In
general, legitimate users know their highest resource value that they
are entitled to.}

The precise effect of the \header{Resource-Priority} indication depends
on the type of UAS, the namespace and local policy.  For example, a
circuit-switched telephony gateway might move requests with elevated
priority to the front of the queue of requests waiting for outbound
lines, it may utilize additional resources or it may preempt existing
calls.  For a terminal, such as a SIP phone, requests with elevated
priority might trigger a special alert tone or preempt other,
lower-priority ongoing calls.  The generic protocol mechanism described
here does not mandate the particular element behavior, but namespace
definitions, such as the ones in Section~\ref{sec:namespace}, need to
spell out the desired behavioral properties of user agents and proxy
servers.
