Editing My SIP notes (section)

== Structure of SIP ==

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 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 [https://tools.ietf.org/html/rfc3261#section-25 Section 25]; an overview of a SIP message's structure can be found in [https://tools.ietf.org/html/rfc3261#section-7 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 [https://tools.ietf.org/html/rfc3261#section-18 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 [https://tools.ietf.org/html/rfc3261#section-17 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.

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 ([https://tools.ietf.org/html/rfc3261#section-8 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.  [https://tools.ietf.org/html/rfc3261#section-10 Section 10] describes UAC and UAS core behavior for the REGISTER method. [https://tools.ietf.org/html/rfc3261#section-11 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.