\section{Structure of the Protocol}
\label{sec:structure}

SIP is structured as a layered protocol, which means that its behavior
is described in terms of a set of fairly independent processing stages
with only a loose coupling between each stage.  The protocol behavior is
described as layers for the purpose of presentation, allowing the
description of functions common across elements in a single section.  It
does not dictate an implementation in any way.  When we say that an
element ``contains'' a layer, we mean it is compliant to the set of
rules defined by that layer. 

Not every element specified by the protocol contains every layer. 
Furthermore, the elements specified by SIP are logical elements, not
physical ones.  A physical realization can choose to act as different
logical elements, perhaps even on a transaction-by-transaction basis. 

The lowest layer of SIP is its syntax and encoding.  Its encoding is
specified using an augmented Backus-Naur Form grammar (BNF).  The
complete BNF is specified in Section~\ref{sec:abnf}; an overview of a
SIP message's structure can be found in Section~\ref{sec:message}.

The second layer is the transport layer.  It defines how a client sends
requests and receives responses and how a server receives requests and
sends responses over the network.  All SIP elements contain a transport
layer.  The transport layer is described in Section~\ref{sec:transport}.

The third layer is the transaction layer.  Transactions are a
fundamental component of SIP.  A transaction is a request sent by a
client transaction (using the transport layer) to a server transaction,
along with all responses to that request sent from the server
transaction back to the client.  The transaction layer handles
application-layer retransmissions, matching of responses to requests,
and application-layer timeouts.  Any task that a user agent client (UAC)
accomplishes takes place using a series of transactions.  Discussion of
transactions can be found in Section~\ref{sec:transactions}.  User
agents contain a transaction layer, as do stateful proxies.  Stateless
proxies do not contain a transaction layer.  The transaction layer has a
client component (referred to as a client transaction) and a server
component (referred to as a server transaction), each of which are
represented by a finite state machine that is constructed to process a
particular request. 

The layer above the transaction layer is called the transaction user
(TU).  Each of the SIP entities, except the stateless proxy, is a
transaction user.  When a TU wishes to send a request, it creates a
client transaction instance and passes it the request along with the
destination IP address, port, and transport to which to send the
request.  A TU that creates a client transaction can also cancel it. 
When a client cancels a transaction, it requests that the server stop
further processing, revert to the state that existed before the
transaction was initiated, and generate a specific error response to
that transaction.  This is done with a {\CANCEL} request, which
constitutes its own transaction, but references the transaction to be
cancelled (Section~\ref{sec:canceling}).

\begin{changebar}
The SIP elements, that is, user agent clients and servers, stateless and
stateful proxies and registrars, contain a \emph{core} that
distinguishes them from each other.  Cores, except for the stateless
proxy, are transaction users.  While the behavior of the UAC and UAS
cores depends on the method, there are some common rules for all methods
(Section~\ref{sec:ua}).  For a UAC, these rules govern the construction
of a request; for a UAS, they govern the processing of a request and
generating a response.  Since registrations play an important role in
SIP, a UAS that handles a {\REGISTER} is given the special name
registrar.  Section~\ref{sec:reg} describes UAC and UAS core behavior for the {\REGISTER} method. Section~\ref{sec:query-for-capabilities} describes UAC and UAS core behavior for the {\OPTIONS} method, used for determining the capabilities of a UA.
\end{changebar}

Certain other requests are sent within a dialog.  A dialog is a
peer-to-peer SIP relationship between two user agents that persists for
some time.  The dialog facilitates sequencing of messages and proper
routing of requests between the user agents.  The {\INVITE} method is
the only way defined in this specification to establish a dialog.  When
a UAC sends a request that is within the context of a dialog, it follows
the common UAC rules as discussed in Section~\ref{sec:ua} but also the
rules for mid-dialog requests.  Section~\ref{sec:dialog} discusses
dialogs and presents the procedures for their construction and
maintenance, in addition to construction of requests within a dialog.

The most important method in SIP is the {\INVITE} method, which is used
to establish a session between participants.  A session is a collection
of participants, and streams of media between them, for the purposes of
communication.  Section~\ref{sec:initiate} discusses how sessions are
initiated, resulting in one or more SIP dialogs.  
Section~\ref{sec:modify} discusses how characteristics of that session are
modified through the use of an {\INVITE} request within a dialog. 
Finally, section~\ref{sec:terminate} discusses how a session is
terminated. 

The procedures of Sections~\ref{sec:ua}, \ref{sec:reg},
\ref{sec:query-for-capabilities}, \ref{sec:dialog}, \ref{sec:initiate},
\ref{sec:modify}, and~\ref{sec:terminate} deal entirely with the UA core
(Section~\ref{sec:canceling} describes cancellation, which applies to
both UA core and proxy core).  Section~\ref{sec:proxy} discusses the
proxy element, which facilitates routing of messages between user
agents.
