\section{Overview of Operation}
\label{sec:overview-of-operations}

This section introduces the basic operations of SIP using simple
examples.  This section is tutorial in nature and does not contain any
normative statements.

The first example shows the basic functions of SIP: location of an 
end point, signal of a desire to communicate, negotiation of session 
parameters to establish the session, and teardown of the session once 
established.

Figure~\ref{fig:trapezoid} shows a typical example of a SIP message 
exchange between two users, Alice and Bob. (Each message is labeled 
with the letter ``F'' and a number for reference by the text.)  In this 
example, Alice uses a SIP application on her PC (referred to as a 
softphone) to call Bob on his SIP phone over the Internet.  Also shown 
are two SIP proxy servers that act on behalf of Alice and Bob to 
facilitate the session establishment.  This typical arrangement is 
often referred to as the ``SIP trapezoid'' as shown by the geometric 
shape of the dashed lines in Figure~\ref{fig:trapezoid}.  

\txtpsfigsize{!}{!}{trapezoid}{SIP session setup example with SIP 
trapezoid}

Alice ``calls'' Bob using his SIP identity, a type of Uniform Resource 
Identifier (URI) called a \emph{SIP URI} and which is defined in 
Section~\ref{sec:sip-url}.  It has a similar form to an email address, 
typically containing a username and a host name.  In this case, it is 
sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP service 
provider (which can be an enterprise, retail provider, etc).  Alice 
also has a SIP URI of sip:alice@atlanta.com.  Alice might have typed in 
Bob's URI or perhaps clicked on a hyperlink or an entry in an address 
book. \begin{changebar} SIP also provides a secure URI, called a SIPS
URI. An example would be sips:bob@biloxi.com. A call made to a SIPS
URI guarantees that secure, encrypted transport (namely TLS) is used
to carry all SIP messages from the caller to the domain of the callee.
From there, the request is sent securely to the callee, but with
security mechanisms that depend on the policy of the domain of the
callee.
\end{changebar}

SIP is based on an HTTP-like request/response transaction model. Each
transaction consists of a request that invokes a particular
\emph{method}, or function, on the server and at least one response. In
this example, the transaction begins with Alice's softphone sending an
{\INVITE} request addressed to Bob's SIP URI.  {\INVITE} is an example
of a SIP method that specifies the action that the requestor (Alice)
wants the server (Bob) to take.  The {\INVITE} request contains a
number of header fields.  Header fields are named
attributes that provide additional information about a message.  The
ones present in an {\INVITE} include a unique identifier for the call,
the destination address, Alice's address, and information about the
type of session that Alice wishes to establish with Bob.  The
{\INVITE} (message F1 in Figure~\ref{fig:trapezoid}) might look like
this:


\begin{verbatim}
  INVITE sip:bob@biloxi.com SIP/2.0
  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
  Max-Forwards: 70
  To: Bob <sip:bob@biloxi.com>
  From: Alice <sip:alice@atlanta.com>;tag=1928301774
  Call-ID: a84b4c76e66710@pc33.atlanta.com
  CSeq: 314159 INVITE
  Contact: <sip:alice@pc33.atlanta.com>
  Content-Type: application/sdp
  Content-Length: 142

  (Alice's SDP not shown)
\end{verbatim}


The first line of the text-encoded message contains the method name 
({\INVITE}).   The lines that follow are a list of header fields.  
This example contains a minimum required set.  The header fields are briefly 
described below:

  \header{Via} contains the address
 (pc33.atlanta.com) at which Alice is expecting to receive responses
 to this request. It also contains a branch parameter that contains an
 identifier for this transaction. 

\header{To} contains a display name (Bob) and a SIP or SIPS URI 
(sip:bob@biloxi.com) towards which the request was originally
directed. Display names are described in RFC~2822~\citenorm{rfc2822}. 

\header{From} also contains a display name (Alice) and a SIP or SIPS URI 
(sip:alice@atlanta.com) that indicate the originator of the request.  
This header field also has a \header{tag} parameter containing a 
pseudorandom string (1928301774) that was added to the URI by the 
softphone.  It is used for identification purposes.

\begin{changebar}
\header{Call-ID} contains a globally unique identifier for this call, 
generated by the combination of a pseudorandom string and the 
softphone's IP address.  The combination of the \header{To} tag, 
\header{From} tag, and \header{Call-ID} completely define a peer-to-peer
SIP relationship between Alice and Bob and is referred to as a \emph{dialog}.
\end{changebar}

\header{CSeq} or Command Sequence contains an integer and a method 
name.  The \header{CSeq} number is incremented for each new request
within a dialog and is a traditional sequence number.

\header{Contact} contains a SIP or SIPS URI that represents a direct route to 
contact Alice, usually composed of a username at a fully qualified 
domain name (FQDN).
While an FQDN is preferred, many end systems do not have registered
domain names, so IP addresses are permitted. While the
\header{Via} header field tells other elements where to send the
response, the \header{Contact} header field tells other elements where
to send future requests.

\header{Max-Forwards} serves to limit the number of hops a request can 
make on the way to its destination. It consists of an integer that is 
decremented by one at each hop. 

\header{Content-Type} contains a description of the message body (not 
shown).

\header{Content-Length} contains an octet (byte) count of the message 
body.

The complete set of SIP header fields is defined in 
Section~\ref{sec:header-fields}.

The details of the session, type of media, codec, sampling rate, etc. 
are not described using SIP.  Rather, the body of a SIP message contains
a description of the session, encoded in some other protocol format. 
One such format is the Session Description Protocol (SDP) 
(RFC~2327~\citenorm{rfc2327}).  This SDP message (not shown in the example) is
carried by the SIP message in a way that is analogous to a document
attachment being carried by an email message, or a web page being
carried in an HTTP message.

Since the softphone does not know the location of Bob or  
the SIP server in the biloxi.com domain, the softphone sends the 
{\INVITE} to the SIP server that serves Alice's domain, atlanta.com.  
The address of the atlanta.com SIP server could have been configured 
in Alice's softphone, or it could have been discovered by DHCP, for
example.

The atlanta.com SIP server is a type of SIP server known as a proxy
server.  A proxy server receives SIP requests and forwards them on
behalf of the requestor.  In this example, the proxy server receives the
{\INVITE} request and sends a 100 (Trying) response back to Alice's
softphone.  The 100 (Trying) response indicates that the {\INVITE} has
been received and that the proxy is working on her behalf to route the
{\INVITE} to the destination.  Responses in SIP use a three-digit code
followed by a descriptive phrase.  This response contains the same
\header{To}, \header{From}, \header{Call-ID},\header{CSeq} and branch parameter in the \header{Via} as the
{\INVITE}, which allows Alice's softphone to correlate this response to
the sent {\INVITE}.  The atlanta.com proxy server locates the proxy
server at biloxi.com, possibly by performing a particular type of DNS
(Domain Name Service) lookup to find the SIP server that serves the
biloxi.com domain.   This is described 
in~\citenorm{draft-ietf-sip-srv}.   As a result, it obtains the
IP address of the biloxi.com proxy server and forwards, or proxies, the
{\INVITE} request there.  Before forwarding the request, the atlanta.com
proxy server adds an additional \header{Via} header field value that contains
its own address (the {\INVITE} already contains Alice's address in
the first \header{Via}).  The biloxi.com proxy server receives the
{\INVITE} and responds with a 100 (Trying) response back to the
atlanta.com proxy server to indicate that it has received the {\INVITE}
and is processing the request.  The proxy server consults a database,
generically called a location service, that contains the current IP
address of Bob.  (We shall see in the next section how this database can
be populated.) The biloxi.com proxy server adds another \header{Via}
header field value with its own address to the {\INVITE} and proxies it to Bob's
SIP phone. 

Bob's SIP phone receives the {\INVITE} and alerts Bob to the incoming
call from Alice so that Bob can decide whether to answer the call,
that is, Bob's phone rings.  Bob's SIP phone indicates this
in a 180 (Ringing) response, which is routed back through the two
proxies in the reverse direction.  Each proxy uses the \header{Via}
header field  to determine where to send the response and removes its own
address from the top.  As a result, although DNS and location service
lookups were required to route the initial {\INVITE}, the 180 (Ringing)
response can be returned to the caller without lookups or without state
being maintained in the proxies.  This also has the desirable property
that each proxy that sees the {\INVITE} will also see all responses to
the {\INVITE}. 

When Alice's softphone receives the 180 (Ringing) response, it passes
this information to Alice, perhaps using an audio ringback tone or by
displaying a message on Alice's screen.

In this example, Bob decides to answer the call.  When he picks up the
handset, his SIP phone sends a 200 (OK) response to indicate that the
call has been answered.  The 200 (OK) contains a message body with the
SDP media description of the type of session that Bob is willing to
establish with Alice.  As a result, there is a two-phase exchange of SDP
messages: Alice sent one to Bob, and Bob sent one back to Alice.  This
two-phase exchange provides basic negotiation capabilities and is based
on a simple offer/answer model of SDP exchange.  If Bob did not wish to
answer the call or was busy on another call, an error response would
have been sent instead of the 200 (OK), which would have resulted in no
media session being established.  The complete list of SIP response
codes is in Section~\ref{sec:response-codes}.  The 200 (OK) (message F9
in Figure~\ref{fig:trapezoid}) might look like this as Bob sends it out:


\begin{changebar}
\begin{verbatim}
  SIP/2.0 200 OK
  Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8
   ;received=192.0.2.3
  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
   ;received=192.0.2.2
  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
   ;received=192.0.2.1
  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
  From: Alice <sip:alice@atlanta.com>;tag=1928301774
  Call-ID: a84b4c76e66710
  CSeq: 314159 INVITE
  Contact: <sip:bob@192.0.2.4>
  Content-Type: application/sdp
  Content-Length: 131

  (Bob's SDP not shown)
\end{verbatim}
\end{changebar}


The first line of the response contains the response code (200) and the
reason phrase (OK).  The remaining lines contain header fields.  The
\header{Via}, \header{To}, \header{From}, \header{Call-ID}, 
and \header{CSeq} header fields are copied from the {\INVITE} request. 
(There are three \header{Via} header field values - one added by Alice's SIP phone,
one added by the atlanta.com proxy, and one added by the biloxi.com
proxy.) Bob's SIP phone has added a \header{tag} parameter to the
\header{To} header field.  This tag will be incorporated by both endpoints 
into the dialog and will be included in all future requests and
responses in this call.  The \header{Contact} header field contains a
URI at which Bob can be directly reached at his SIP phone.  The
\header{Content-Type} and \header{Content-Length} refer to the message
body (not shown) that contains Bob's SDP media information. 

In addition to DNS and location service lookups shown in this example,
proxy servers can make flexible ``routing decisions'' 
to decide where to send a request.  For example, if Bob's SIP
phone returned a 486 (Busy Here) response, the biloxi.com proxy server
could proxy the {\INVITE} to Bob's voicemail server.  A proxy server
can also send an {\INVITE} to a number of locations at the same time.
This type of parallel search is known as \emph{forking}.

In this case, the 200 (OK) is routed back through the two proxies and is 
received by Alice's softphone, which then stops the ringback tone and 
indicates that the call has been answered.  Finally, Alice's softphone sends an 
acknowledgement message, {\ACK} to Bob's SIP phone to confirm the reception of 
the final response (200 (OK)).  In this example, the {\ACK} is 
sent directly from Alice's softphone to Bob's SIP phone, 
bypassing the two proxies.  This occurs 
because the endpoints have learned each other's address from the 
\header{Contact} header fields through the {\INVITE}/200 (OK) exchange, 
which was not known when the 
initial {\INVITE} was sent.  The lookups performed by the two proxies 
are no longer needed, so the proxies drop out of the call flow.  This 
completes the {\INVITE}/200/{\ACK} three-way handshake used to 
establish SIP sessions.  Full 
details on session setup are in Section~\ref{sec:initiate}.

Alice and Bob's media session has now begun, and they send 
media packets using the format to which they agreed in the exchange of SDP. 
In general, the end-to-end media packets take a different path from 
the SIP signaling messages.

During the session, either Alice or Bob may decide to change the 
characteristics of the media session.  This is accomplished by sending 
a re-{\INVITE} containing a new media description.  This re-{\INVITE} 
references the existing dialog so that the other party knows that it 
is to modify an existing session instead of establishing a new session. 
The other party sends a 200 (OK) to accept the change. The requestor
responds to the 200 (OK) with an {\ACK}. If the other party does not
accept the change, he sends an error response such as 406 (Not Acceptable),
which also receives an {\ACK}.  However, the failure 
of the re-{\INVITE} does not cause the existing call to fail - the 
session continues using the previously negotiated characteristics.  
Full details on session modification are in Section~\ref{sec:modify}.

At the end of the call, Bob disconnects (hangs up) first and generates 
a {\BYE} message.  This {\BYE} is routed directly to Alice's softphone, 
again bypassing the proxies.  Alice confirms receipt of the {\BYE} with 
a 200 (OK) response, which terminates the session and the {\BYE} 
transaction.  No {\ACK} is sent - an {\ACK} is only sent in 
response to a response to an {\INVITE} request.  The reasons for this 
special handling for {\INVITE} will be discussed later, but relate to 
the reliability mechanisms in SIP, the length of time it can take for a 
ringing phone to be answered, and forking.  For this reason, request 
handling in SIP is often classified as either {\INVITE} or non-{\INVITE}, 
referring to all other methods besides {\INVITE}. Full 
details on session termination are in Section~\ref{sec:terminate}.

Full details of all the messages shown in the example of 
Figure~\ref{fig:trapezoid} are shown in 
Section~\ref{sec:examples:session-setup}.

In some cases, it may be useful for proxies in the SIP signaling path to 
see all the messaging between the endpoints for the duration of the 
session.  For example, if the biloxi.com proxy server wished to remain 
in the SIP messaging path beyond the initial {\INVITE}, it would add to 
the {\INVITE} a required routing header field known as
\header{Record-Route} that contained a URI resolving to the hostname
or IP address of the proxy.  This information 
would be received by both Bob's SIP phone and (due to the 
\header{Record-Route} header field being passed back in the 200 (OK)) 
Alice's softphone and stored for the duration of the dialog. 
The biloxi.com proxy server would then receive and proxy
the {\ACK}, {\BYE}, and 200 (OK) to the {\BYE}.  Each proxy can 
independently decide to receive subsequent messaging, and that 
messaging will go through all proxies that elect to receive it.    
This capability is frequently used for proxies that are providing
mid-call features.

Registration is another common operation in SIP.  Registration is one
way that the biloxi.com server can learn the current location of
Bob.  Upon initialization, and at periodic intervals, Bob's SIP phone
sends {\REGISTER} messages to a server in the biloxi.com domain known as
a SIP registrar. The {\REGISTER} messages associate Bob's SIP or SIPS URI
(sip:bob@biloxi.com) with the machine into which he is currently logged  
(conveyed as a SIP or SIPS URI in the \header{Contact} header field). The registrar
writes this association, also called a binding, to a database, called
the \emph{location service}, where it can be used by the proxy in the
biloxi.com domain. Often, a registrar server for a domain is
co-located with the proxy for that domain. It is an important concept
that the distinction between types of SIP servers is logical, not
physical.

Bob is not limited to registering from a single 
device.  For example, both his SIP phone at home and the one in the 
office could send registrations. This information is stored together 
in the location service and allows a proxy to perform various types of 
searches to locate Bob.  Similarly, more than one user can be 
registered on a single device at the same time.

The location service is just an abstract concept.  It generally 
contains information that allows a proxy to input a URI and receive a 
set of zero or more URIs that tell the proxy where to send the request.  
Registrations are one way to create this information, but not the only 
way.  Arbitrary mapping functions can be configured at the 
discretion of the administrator.  

Finally, it is important to note that in SIP, registration is used for 
routing incoming SIP requests and has no role in authorizing outgoing 
requests. Authorization and authentication are handled in SIP either 
on a request-by-request basis with a challenge/response mechanism,
or by using a lower layer scheme as discussed in Section~\ref{sec:security}.

The complete set of SIP message details for this registration example 
is in Section~\ref{sec:examples:registration}. 


Additional operations in SIP, such as querying for the capabilities of a 
SIP server or client using {\OPTIONS}, or canceling a pending request
using {\CANCEL}, will be introduced in later sections.


