5. Structure of the Protocol

   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 25; an overview of a SIP
   message's structure can be found in Section 7.

   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 18.

   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 17.  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 9).

   The SIP elements, that is, user agent clients and servers, stateless
   and stateful proxies and registrars, contain a 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 8).  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 10 describes UAC and UAS core behavior for the
   REGISTER method.  Section 11 describes UAC and UAS core behavior for
   the OPTIONS method, used for determining the capabilities of a UA.

   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 8 but
   also the rules for mid-dialog requests.  Section 12 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 13 discusses how sessions are
   initiated, resulting in one or more SIP dialogs.  Section 14
   discusses how characteristics of that session are modified through
   the use of an INVITE request within a dialog.  Finally, section 15
   discusses how a session is terminated.

   The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
   entirely with the UA core (Section 9 describes cancellation, which
   applies to both UA core and proxy core).  Section 16 discusses the
   proxy element, which facilitates routing of messages between user
   agents.