\section{Introduction}
\label{sec:intro}

\subsection{Overview of SIP Functionality}
\label{sec:overview}
  
The Session Initiation Protocol (SIP) is an application-layer control
protocol that can establish, modify and terminate multimedia sessions
(conferences) or Internet telephony calls.  SIP can invite participants
to unicast and multicast sessions; the initiator does not necessarily
have to be a member of the session to which it is inviting.  Media and
participants can be added to an existing session.

SIP transparently supports name mapping and redirection services,
allowing the implementation of ISDN and Intelligent Network telephony
subscriber services.  These facilities also enable {\em personal
mobility.} In the parlance of telecommunications intelligent network
services, this is defined as:  ``Personal mobility is the ability of end
users to originate and receive calls and access subscribed
telecommunication services on any terminal in any location, and the
ability of the network to identify end users as they move.  Personal
mobility is based on the use of a unique personal identity (i.e.,
personal number).'' \cite[p.~44]{Pand9506:Emerging}.  Personal
mobility complements terminal mobility, i.e., the ability to maintain
communications when moving a single end system from one subnet to
another.

SIP supports five facets of establishing and terminating
multimedia communications:
\begin{description}
\item[User location:] determination of the end system to be used for
communication;

\item[User capabilities:] determination of the media and media
parameters to be used;

\item[User availability:] determination of the willingness of the called
party to engage in communications;

\item[Call setup:] ``ringing'', establishment of call parameters at both
called and calling party;

\item[Call handling:] including transfer and termination of
calls.

\end{description}

SIP is designed as part of the overall IETF multimedia data and control
architecture currently incorporating protocols such as RSVP (RFC 2205
\cite{rfc2205}) for reserving network resources, the real-time transport
protocol (RTP) (RFC 1889 \cite{rfc1889}) for transporting real-time
data and providing QOS feedback, the real-time streaming protocol
(RTSP) (RFC 2326 \cite{rfc2326}) for controlling delivery of
streaming media, the session announcement protocol (SAP)
\cite{rfc2974} for advertising multimedia sessions via
multicast and the session description protocol (SDP) (RFC 2327
\cite{rfc2327}) for describing multimedia sessions. However, the
functionality and operation of SIP does not depend on any of these
protocols.

SIP does not offer conference control services such as floor control or
voting and does not prescribe how a conference is to be managed, but SIP
can be used to introduce conference control protocols.  SIP does not
allocate multicast addresses and does not reserve network resources.

\subsection{Terminology}
\label{sec:terminology}

In this document, the key words ``{\MUST}'', ``{\MUSTNOT}'',
``{\REQUIRED}'', ``{\SHALL}'', ``{\SHALLNOT}'', ``{\SHOULD}'',
``{\SHOULDNOT}'', ``{\RECOMMENDED}'', ``{\MAY}'', and ``{\OPTIONAL}''
are to be interpreted as described in RFC 2119 \cite{rfc2119} and
indicate requirement levels for compliant SIP implementations.

\subsection{Overview of SIP Operation}
\label{sec:operation}

This section explains the basic protocol functionality and operation.
Terms are defined more precisely in Section~\ref{sec:definitions}.  In
SIP, protocol participants are identified by SIP URLs, described in
Section~\ref{sec:addressing}.  SIP is a request-response protocol,
with requests sent by clients and received by servers.  A single
implementation typically combines both client and server
functionality.  SIP requests can be sent using any reliable or
unreliable protocol, including UDP, SCTP \cite{rfc2960} and
TCP. Protocol operation is largely independent of the lower-layer
transport protocol.

This specification defines six SIP request methods:  {\INVITE}
(Section~\ref{sec:INVITE}) initiates sessions, {\ACK}
(Section~\ref{sec:ACK}) confirms session establishment, {\OPTIONS}
(Section~\ref{sec:OPTIONS}) requests information about capabilities,
{\BYE} (Section~\ref{sec:BYE}) terminates a sessions, {\CANCEL}
(Section~\ref{sec:CANCEL}) cancels a pending session and {\REGISTER}
(Section~\ref{sec:REGISTER}) allows a client to bind a permanent SIP URL
to a temporary SIP URL reflecting the current network location.

SIP requests and responses consists of a request (or status) line, a
number of header lines and a message body (Section~\ref{sec:message}).

SIP requests can be sent directly from a user agent client to a user
agent server, or they can traverse one or more proxy servers along the
way.  Often, proxy servers are associated with DNS domains, similar to
SMTP MTAs. 

User agents send requests either directly to the address indicated in
the SIP URI or to a designated proxy (``outbound proxy''), independent
of the destination address.  The current destination address is carried
in the \header{Request-URI}.  Each proxy can forward the request based
on local policy and information contained in the SIP request.  The proxy
{\MAY} rewrite the request URI.  A proxy {\MAY} also forward the request
to another designated proxy regardless of the request URI.  For example,
a departmental proxy could forward all authorized requests to a
corporate-wide proxy which then forwards it to the proxy operated by the
Internet service provider, which finally routes the request based on the
request URI.

Proxies {\MAY} modify any part of the SIP message that are not
integrity-protected, except those needed to identify call legs. Proxies
generally do not modify the session description, but {\MAY} do so.

For example, if the user agent wants to contact the user
\texttt{sip:alice@example.com}, it sends the request to the server
handling the \texttt{example.com} domain (Section~\ref{sec:server}).  If
that host acts as a proxy server, it looks up whether it has a mapping
from \texttt{alice@example.com} to another address.  If so, it
substitutes that address, say \texttt{alice@sales.example.com}, into the
\header{Request-URI} and then sends the request to the server for the
\texttt{sales.example.com} domain.  Any server can also return a
response indicating a different destination to be tried by the upstream
client or indicating that the request cannot be forwarded.

Typically, only the first request within a call traverses all proxies,
while subsequent requests are exchanged directly between user agents.
However, a proxy can indicate that it wants to remain in the request
path via a \header{Record-Route} (Section~\ref{sec:Record-Route}) header
field.

\subsection{Definitions}
\label{sec:definitions}

This specification uses a number of terms to refer to the roles played
by participants in SIP communications.  The definitions of client,
server and proxy are similar to those used by the Hypertext Transport
Protocol (HTTP) (RFC 2616 \cite{rfc2616}).  The terms and generic syntax
of URI and URL are defined in RFC 2396 \cite{rfc2396}.  The following
terms have special significance for SIP.

\begin{description}

\item[Back-To-Back User Agent:] Also known as a B2BUA, this is a logical
entity that receives an invitation, and acts as a UAS to process it.  In
order to determine how the request should be answered, it acts as a UAC
and initiates a call outwards.  Unlike a proxy server, it maintains
complete call state and must participate in all requests for a call.
Since it is purely a concatenation of other logical functions, no
explicit definitions are needed for its behavior.

\item[Call:] A call consists of all participants in a session invited
by a common source.  A SIP call is identified by a globally unique
call-id (Section~\ref{sec:Call-ID}), and is created when a user agent
sends an {\INVITE} request. This {\INVITE} request may generate
multiple acceptances, each of which are part of the same call (but
different call legs). Furthermore, if a user is invited to the same
multicast session by several people, each of these 
invitations will be a unique call.  In a multiparty conference
unit (MCU) based call-in conference, each participant uses a separate
call to invite himself to the MCU.

\item[Call leg:] A call leg is a pairwise signaling relationship
between two SIP user agents. A call leg is established when a call
invitation results in a successful response. It is identified by the
combination of the 
\header{Call-ID} header field, the local address of the participant,
and the remote address of the other participant. For the caller, the
local address is the \header{From} field of the {\INVITE}, and the
remote address is the \header{To} field of the 200 class response. For
the callee, the local address is the \header{To} field of the 200
class response to the {\INVITE}, and the remote address is the
\header{From} field of the {\INVITE}.  SIP
URIs are compared according to Section~\ref{sec:uri_comparison},
non-SIP URIs according to Section~\ref{sec:nonsipuri_comparison}.
Within the same \header{Call-ID}, requests with \header{From} $A$ and
\header{To} value $B$ belong to the same call leg as the requests in
the opposite direction, i.e., \header{From} $B$ and \header{To} $A$.

\item[Call Stateful:] A proxy is said to be {\em call stateful} when
it retains state that persists for the duration of a call initiated
through it. To properly manage that state, the proxy will normally
need to receive the {\BYE} requests that terminate the call.

\item[Client:] An application program that sends SIP requests.  Clients
may or may not interact directly with a human user.  {\em User agents}
and {\em proxies} contain clients (and servers).

\item[Conference:] A multimedia session (see below), identified by a
common session description.  A conference can have zero or more members
and includes the cases of a multicast conference, a full-mesh conference
and a two-party ``telephone call'', as well as combinations of these. 
Any number of calls can be used to create a conference.

\item[Downstream:] Requests sent in the direction from the caller to the
callee (i.e., user agent client to user agent server).

\item[Final response:] A response that terminates a SIP transaction, as
opposed to a {\em provisional response} that does not.  All 2xx, 3xx,
4xx, 5xx and 6xx responses are final.

\item[Initiator, calling party, caller:] The party initiating a session
invitation.  Note that the calling party does not have to be the same as
the one creating the conference. A caller retains this role for the
duration of a call.

\item[Invitation:] A request sent to a user (or service) requesting
participation in a session.  A successful SIP invitation consists of two
transactions:  an {\INVITE} request followed by an {\ACK} request.

\item[Invitee, invited user, called party, callee:] The person or
service that the calling party is trying to invite to a conference. A
callee retains this role for the duration of a call.

\item[Isomorphic request or response:] Two requests or responses are
defined to be {\em isomorphic} for the purposes of this document if they
have the same values for the \header{Call-ID}, \header{To},
\header{From} and \header{CSeq} header fields.  In addition, isomorphic
requests have to have the same \header{Request-URI} and the same
top-most \header{Via} header.

\item[Location server:] See {\em location service.}

\item[Location service:] A location service is used by a SIP redirect or
proxy server to obtain information about a callee's possible
location(s).  Examples of sources of location information include SIP
registrars, databases or mobility registration protocols.  Location
services are offered by location servers.  Location servers {\MAY} be
part of a SIP server, but the manner in which a SIP server requests
location services is beyond the scope of this document.

\item[Outbound proxy:] A {\em proxy} that is located near the originator
of requests.  It receives all outgoing requests {\bf from} a particular
UAC, including those requests whose \header{Request-URL}s identify a
host other than the outbound proxy.  The outbound proxy sends these
requests, after any local processing, to the address indicated in the
\header{Request-URI}.  (All other proxy servers are simply referred as
proxies, not {\em inbound} proxies.)

\item[Parallel search:] In a parallel search, a proxy issues several
requests to possible user locations upon receiving an incoming request. 
Rather than issuing one request and then waiting for the final response
before issuing the next request as in a {\em sequential search}, a
parallel search issues requests without waiting for the result of
previous requests. 

\item[Provisional response:] A response used by the server to indicate
progress, but that does not terminate a SIP transaction. 1xx 
responses are provisional, other responses are considered {\em final.}

\item[Proxy, proxy server:] An intermediary program that acts as both a
server and a client for the purpose of making requests on behalf of
other clients.  Requests are serviced internally or by passing them on,
possibly after translation, to other servers.  A proxy interprets, and,
if necessary, rewrites a request message before forwarding it. 

\motivation{Proxy servers are, for example, used to route requests,
enforce policies, control firewalls.}

\item[Redirect server:] A redirect server is a server that accepts a SIP
request, maps the address into zero or more new addresses and returns
these addresses to the client.  Unlike a {\em proxy server}, it does not
initiate its own SIP request.  Unlike a {\em user agent server}, it does not
accept calls.

\item[Registrar:] A registrar is a server that accepts {\REGISTER}
requests.  A registrar is typically co-located with a proxy or redirect
server and {\MAY} make its information available through the location
server.

\item[Regular Transaction:] A regular transaction is any transaction
with a method other than {\INVITE}, {\ACK}, or {\CANCEL}.

\item[Ringback:] Ringback is the signaling tone produced by the calling
client's application indicating that a called party is being alerted
(ringing).

\item[Server:] A server is an application program that accepts requests
in order to service requests and sends back responses to those requests. 
Servers are either proxy, redirect or user agent servers or registrars.  

\item[Sequential search:] In a sequential search, a proxy server
attempts each contact address in sequence, proceeding to the next one
only after it has returned a 4xx or 5xx response or the address entry
has not returned any final response within the proxy-chosen timeout
period.

\item[Session:] From the SDP specification:  ``A multimedia session is a
set of multimedia senders and receivers and the data streams flowing
from senders to receivers.  A multimedia conference is an example of a
multimedia session.'' (RFC 2327 \cite{rfc2327}) (A session as defined
for SDP can comprise one or more RTP sessions.) As defined, a callee can
be invited several times, by different calls, to the same session.  If
SDP is used, a session is defined by the concatenation of the {\it user
name}, {\it session id}, {\it network type}, {\it address type} and {\it
address} elements in the origin field.

\item[(SIP) transaction:] A SIP transaction occurs between a client and
a server and comprises all messages from the first request sent from the
client to the server up to a final (non-1xx) response sent from the
server to the client.  A transaction is identified by the \header{CSeq}
sequence number (Section~\ref{sec:CSeq}) within a single {\em call leg.} 
The {\ACK} request has the same \header{CSeq} number as the
corresponding {\INVITE} request, but comprises a transaction of its
own.

\item[Spiral:] A spiral is a SIP request which is routed to a proxy,
forwarded onwards, and arrives once again at that proxy, but this
time, with a \header{Request-URI} that differs from the previous
arrival. A spiral is not an error condition, unlike a loop.

\item[Stateless Proxy:] A logical entity that does not maintain state
for a SIP transaction. A stateless proxy forwards every request
it receives downstream and every response it receives upstream.

\item[Stateful Proxy:] A logical entity that maintains state information
for the duration of a SIP transaction.  Also known as a transaction
stateful proxy. The behavior of a stateful proxy is further defined in
Section~\ref{sec:proxy}. A stateful proxy is not the same as a call
stateful proxy.

\item[Upstream:] Responses sent in the direction from the user agent
server to the user agent client.

\item[URL-encoded:] A character string encoded according to RFC 1738,
Section 2.2 \cite{rfc1738}.

\item[User agent client (UAC):] A user agent client is a logical
entity that initiates a SIP transaction with a request. This role
lasts only for the duration of that transaction. In other words, if a
piece of software initiates a request, it acts as a UAC for the
duration of that request. If it receives a request later on, it takes
on the role of a User Agent Server for the processing of that
transaction. 

\item[User agent server (UAS):] A user agent server is a logical
entity that responds to a SIP request, generally acting on behalf of
some user. The response accepts, rejects or redirects the request. This role
lasts only for the duration of that transaction. In other words, if a
piece of software responds to a request, it acts as a UAS for the
duration of that request. If it generates a request later on, it takes
on the role of a User Agent Client for the processing of that
transaction. 

\item[User agent (UA):] A logical entity which acts as both a user agent
client and user agent server for the duration of a call.

\end{description}

An application program {\MAY} be capable of acting both as a client and
a server.  For example, a typical multimedia conference control
application would act as a user agent client to initiate calls or to
invite others to conferences and as a user agent server to accept
invitations.  The role of UAC and UAS as well as proxy and redirect
servers are defined on a request-by-request basis.  For example, the
user agent initiating a call acts as a UAC when sending the initial
{\INVITE} request and as a UAS when receiving a {\BYE} request from the
callee.  Similarly, the same software can act as a proxy server for one
request and as a redirect server for the next request.

Proxy, redirect, location and registrar servers defined above are {\em
logical} entities; implementations {\MAY} combine them into a single
application program.  The properties of the different SIP server types
are summarized in Table~\ref{tab:servers}.

\begin{table}[htpb]
\begin{center}
\begin{tabular}{lcccc}
property     & redirect & proxy  & user agent & registrar\\
             & server   & server & server\\
\hline
also acts as a SIP client       &  no & yes &  no & no\\
inserts \header{Via} header     &  no & yes &  no & no\\
accepts {\ACK}                  & yes & yes & yes & no\\
\end{tabular}
\end{center}
\caption{Properties of the different SIP server types}
\label{tab:servers}
\end{table}

\subsubsection{SIP Addressing}
\label{sec:addressing}

The ``objects'' addressed by SIP are users at hosts, identified by a SIP
URL.  The SIP URL takes a form similar to a \header{mailto} or
\header{telnet} URL, i.e., {\em user@host.}  The {\em user} part is a
user name or a telephone number.  The {\em host} part is either a
domain name or a numeric network address. See
section \ref{sec:sip-url} for a detailed discussion of SIP URL's.

A user's SIP address can be obtained out-of-band, can be learned via
existing media agents, can be included in some mailers' message headers,
or can be recorded during previous invitation interactions.
In many cases, a user's SIP URL can be guessed from their email address. 

A SIP URL address can designate an individual (possibly located at one
of several end systems), the first available person from a group of
individuals or a whole group.  The form of the address, for example,
{\tt sip:sales@example.com}, is not sufficient, in general, to determine
the intent of the caller.

If a user or service chooses to be reachable at an address that is
guessable from the person's name and organizational affiliation, the
traditional method of ensuring privacy by having an unlisted ``phone''
number is compromised.  However, unlike traditional telephony, SIP
offers authentication and access control mechanisms and can avail itself
of lower-layer security mechanisms, so that client software can reject
unauthorized or undesired call attempts.

\subsubsection{Locating a SIP Server}
\label{sec:server}

The \header{Request-URI} is determined according to the rules in
Section~\ref{sec:rr} and can be derived from either the \header{Route},
\header{Contact} or \header{To} header fields.

\input{lookup}

The results of the DNS lookup operation do not, in general, lead to a
modification of the \header{Request-URI}.  \motivation{A proxy is free
to modify the \header{Request-URI} to any value desired, but the DNS
lookups are usually based on the \header{Request-URI} obtained from a
location server.}

\motivation{If the DNS time-to-live value exceeds a few minutes, servers
generating a large number of requests are probably well advised to retry
failed servers every few minutes.}

\subsubsection{SIP Transaction}
\label{sec:transaction}

Once the {\em host} part has been resolved to a SIP server, the client
sends one or more SIP requests to that server and receives one or more
responses from the server.  A request (and its retransmissions) together
with the responses triggered by that request make up a SIP transaction. 
All responses to a request contain the same values in the
\header{Call-ID}, \header{CSeq}, \header{To}, and \header{From} fields
(with the possible addition of a tag in the \header{To} field (section
\ref{sec:To})).  This allows responses to be matched with requests.  The
{\ACK} request confirming the receipt of an {\INVITE} response is {\em
not} part of the transaction since it may traverse a different set of
hosts.

If a reliable stream protocol is used, request and responses within a
single SIP transaction are carried over the same connection (see
Section~\ref{sec:transport}).  Several SIP requests from the same client
to the same server {\MAY} use the same connection or {\MAY} use a new
connection for each request. 

If a client sends the request via a unicast datagram protocol such as
UDP, the receiving user agent directs the response according to the
information contained in the \header{Via} header fields
(Section~\ref{sec:Via}).  Each proxy server in the forward path of the
request forwards the response using these \header{Via} header fields, as
described in detail in Sections~\ref{sec:Via:responses} and
\ref{sec:Via:UAS}.  For datagram protocols, reliability is achieved
using retransmission (Section~\ref{sec:transport}).

\subsubsection{Initiating a Session}
\label{sec:invitation}

A session is initiated with the {\INVITE} request.  A successful SIP
invitation consists of two requests, {\INVITE} followed by {\ACK}.  The
{\INVITE} (Section~\ref{sec:INVITE}) request asks the callee to join a
particular conference or establish a two-party conversation.  After the
callee has agreed to participate in the call, the caller confirms that
it has received that response by sending an {\ACK}
(Section~\ref{sec:ACK}) request.

The {\INVITE} request typically contains a session description, for
example written in SDP (RFC 2327 \cite{rfc2327}) format, that provides
the called party with enough information to join the session.  For
multicast sessions, the session description enumerates the media types
and formats that are allowed to be distributed to that session.  For a
unicast session, the session description enumerates the media types and
formats that the caller is willing to use and where it wishes the media
data to be sent.  In either case, if the callee wishes to accept the
call, it responds to the invitation by returning a similar description
listing the media it wishes to use.  For a multicast session, the
callee {\SHOULD} only return a session description if it is unable to
receive the media indicated in the caller's description or wants to
receive data via unicast.

%The session description may refer to a session start time in the future. 
%Actual transmission of data {\SHOULDNOT} start until the time indicated in
%the session description.

The protocol exchanges for the {\INVITE} method are shown in
Fig.~\ref{fig:sip_proxy} for a proxy server and in Fig.~\ref{fig:redirect}
for a redirect server.  (Note that the messages shown in the figures
have been abbreviated slightly.) In Fig.~\ref{fig:sip_proxy}, the proxy
server accepts the {\INVITE} request (step 1), contacts the location
service with all or parts of the address (step 2) and obtains a more
precise location (step 3).  The proxy server then issues a SIP
{\INVITE} request to the address(es) returned by the location service
(step 4).  The user agent server alerts the user (step 5) and returns
a success indication to the proxy server (step 6).  The proxy server
then returns the success result to the original caller (step 7).  The
receipt of this message is confirmed by the caller using an {\ACK}
request, which is forwarded to the callee (steps 8 and 9).  Note that
an {\ACK} can also be sent directly to the callee, bypassing the
proxy. All requests and responses have the same \header{Call-ID}.

\txtpsfigsize{\textwidth}{!}{sip_proxy}{Example of SIP proxy server}

The redirect server shown in Fig.~\ref{fig:redirect} accepts the
{\INVITE} request (step 1), contacts the location service as before
(steps 2 and 3) and, instead of contacting the newly found address
itself, returns the address to the caller (step 4), which is then
acknowledged via an {\ACK} request (step 5).  The caller issues a new
request, with the same \header{call-ID} but a higher \header{CSeq}, to
the address returned by the first server (step 6).  In the example, the
call succeeds (step 7).  The caller and callee complete the handshake
with an {\ACK} (step 8).

\txtpsfigsize{\textwidth}{!}{redirect}{Example of SIP redirect server}

The next section discusses what happens if the location service returns
more than one possible alternative.

\subsubsection{Locating a User}
\label{sec:locating}

A callee may move between a number of different end systems over time. 
These locations can be dynamically registered with the SIP server
(Sections~\ref{sec:registration}, \ref{sec:REGISTER}).  A location
server {\MAY} also use one or more other protocols, such as finger (RFC
1288 \cite{rfc1288}), rwhois (RFC 2167 \cite{rfc2167}), LDAP (RFC 1777
\cite{rfc1777}), multicast-based protocols \cite{Scho9608:Multicast} or
operating-system dependent mechanisms to actively determine the end
system where a user might be reachable.  A location server {\MAY} return
several locations because the user is logged in at several hosts
simultaneously or because the location server has (temporarily)
inaccurate information.  The SIP server combines the results to yield a
list of a zero or more locations. 

The action taken on receiving a list of locations varies with the type
of SIP server.  A SIP redirect server returns the list to the client as
\header{Contact} headers (Section~\ref{sec:Contact}).  A SIP proxy
server can sequentially or in parallel try the addresses until the call
is successful (2xx response) or the callee has declined the call (6xx
response).  With sequential attempts, a proxy server can implement an
``anycast'' service.

If a proxy server forwards a SIP request, it {\MUST} add itself to the
beginning of the list of forwarders noted in the \header{Via} (Section
\ref{sec:Via}) headers.  The \header{Via} trace ensures that replies can
take the same path back, ensuring correct operation through compliant
firewalls and avoiding request loops.  On the response path, each host
{\MUST} remove its \header{Via}, so that routing internal information is
hidden from the callee and outside networks. 

A SIP invitation may traverse more than one SIP proxy server.  If one of
these ``forks'' the request, i.e., issues more than one request in
response to receiving the invitation request, it is possible that a
client is reached, independently, by more than one copy of the
invitation request.  Each of these copies bears the same
\header{Call-ID}, but a different topmost \header{Via} header branch
parameter (see Section~\ref{sec:Via}).  The user agent {\MAY} choose
which final response to return for each such request, typically
returning a 200 (OK) for only one of them.

\subsubsection{Changing an Existing Session}
\label{sec:changing}

In some circumstances, it is desirable to change the parameters of an
existing session.  This is done by re-issuing the {\INVITE} within the
same call leg, but within a new or different body or header fields to
convey the new information.  This re {\INVITE} {\MUST} have a higher
\header{CSeq} than any previous request from the client to the server.

For example, two parties may have been conversing and
then want to add a third party, switching to multicast for efficiency. 
One of the participants invites the third party with the new multicast
address and simultaneously sends an {\INVITE} to the second party, with
the new multicast session description, but with the old call identifier.

\subsubsection{Registration Services}
\label{sec:registration}

The {\REGISTER} request allows a client to let a proxy or redirect
server know at which address(es) it can be reached.  A client {\MAY}
also use it to install call handling features at the server.

\subsection{Protocol Properties}
\label{sec:properties}

\subsubsection{Minimal State}

A single conference session or call involves one or more SIP
request-response transactions.  Proxy servers do not have to keep state
for a particular call, however, they {\MAY} maintain state for a single
SIP transaction, as discussed in Section~\ref{sec:searching}.  For
efficiency, a server {\MAY} cache the results of location service
requests.

\subsubsection{Lower-Layer-Protocol Neutral}

SIP makes minimal assumptions about the underlying transport and
network-layer protocols.  The lower-layer can provide either a packet or
a byte stream service, with reliable or unreliable service.

In an Internet context, SIP is able to utilize both UDP and TCP as
transport protocols, among others.  UDP allows the application to more
carefully control the timing of messages and their retransmission, to
perform parallel searches without requiring TCP connection state for
each outstanding request, and to use multicast.  Routers can more
readily snoop SIP UDP packets.  TCP allows easier passage through
existing firewalls. 

When TCP is used, SIP can use one or more connections to attempt to
contact a user or to modify parameters of an existing conference. 
Different SIP requests for the same SIP call {\MAY} use different TCP
connections or a single persistent connection, as appropriate.

For concreteness, this document will only refer to Internet protocols.
However, SIP {\MAY} also be used directly with protocols such as ATM
AAL5, IPX, frame relay or X.25.  The necessary naming conventions are
beyond the scope of this document. All entities
{\MUST} support UDP. User agents {\SHOULD} implement TCP transport.
Stateful proxy, registrar, and redirect servers {\MUST} implement TCP
transport. Other transports {\MAY} be supported by any entity.

\subsubsection{Text-Based}

SIP is text-based, using ISO 10646 in UTF-8 encoding throughout.  This
allows easy implementation in languages such as Java, Tcl and Perl,
allows easy debugging, and most importantly, makes SIP flexible and
extensible.  As SIP is used for initiating multimedia conferences rather
than delivering media data, it is believed that the additional overhead
of using a text-based protocol is not significant.
