\section{Examples}
\label{sec:examples}

In the following examples, we often omit the message body and the
corresponding \header{Content-Length} and \header{Content-Type} headers
for brevity.

\subsection{Registration}
\label{sec:ex_registration}

A user at host \host{saturn.bell-tel.com} registers on start-up, via
multicast, with the local SIP server named \host{bell-tel.com}.  In
the example, the user agent on \host{saturn} expects to receive SIP
requests on UDP port 3890.

\begin{verbatim}
C->S: REGISTER sip:bell-tel.com SIP/2.0
      Via: SIP/2.0/UDP saturn.bell-tel.com
      From: <sip:watson@bell-tel.com>;tag=19al
      To: sip:watson@bell-tel.com 
      Call-ID: 70710@saturn.bell-tel.com
      CSeq: 1 REGISTER
      Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>
      Expires: 7200
\end{verbatim}

The registration expires after two hours.  Any future invitations for
\host{watson@bell-tel.com} arriving at \host{sip.bell-tel.com} will now be
redirected to \host{watson@saturn.bell-tel.com}, UDP port 3890.

If Watson wants to be reached elsewhere, say, an on-line service he uses
while traveling, he updates his reservation after first cancelling any
existing locations:

\begin{verbatim}
C->S: REGISTER sip:bell-tel.com SIP/2.0
      Via: SIP/2.0/UDP saturn.bell-tel.com
      From: <sip:watson@bell-tel.com>;tag=19al
      To: sip:watson@bell-tel.com
      Call-ID: 70710@saturn.bell-tel.com
      CSeq: 2 REGISTER
      Contact: *
      Expires: 0

C->S: REGISTER sip:bell-tel.com SIP/2.0
      Via: SIP/2.0/UDP saturn.bell-tel.com
      From: <sip:watson@bell-tel.com>;tag=19al
      To: sip:watson@bell-tel.com 
      Call-ID: 70710@saturn.bell-tel.com
      CSeq: 3 REGISTER
      Contact: sip:tawatson@example.com
\end{verbatim}

Now, the server will forward any request for Watson to the server at
\host{example.com}, using the \header{Request-URI}
\host{tawatson@example.com}.  For the server at \host{example.com} to
reach Watson, he will need to send a {\REGISTER} there, or inform the
server of his current location through some other means.

It is possible to use third-party registration. Here, the secretary
\host{jon.diligent} registers his boss, T. Watson:
\begin{verbatim}
C->S: REGISTER sip:bell-tel.com SIP/2.0
      Via: SIP/2.0/UDP pluto.bell-tel.com
      From: <sip:jon.diligent@bell-tel.com>;tag=7eff
      To: sip:watson@bell-tel.com 
      Call-ID: 17320@pluto.bell-tel.com
      CSeq: 1 REGISTER
      Contact: sip:tawatson@example.com
\end{verbatim}

The request could be sent to either the registrar at \host{bell-tel.com}
or the server at \host{example.com}.  In the latter case, the server at
\host{example.com} would proxy the request to the address indicated in
the \header{Request-URI}.  Then, \header{Max-Forwards} header could be
used to restrict the registration to that server. 

\subsection{Invitation to a Multicast Conference}
\label{sec:invite-example}

The first example invites \host{bob@example.com} to a multicast session. 
All examples use the Session Description Protocol (SDP) (RFC 2327
\cite{rfc2327}) as the session description format.

\subsubsection{Request}

\begin{verbatim}
C->S: INVITE sip:bob@one.example.com SIP/2.0
      Via: SIP/2.0/UDP sip.example.com;branch=7c337f30d7ce.1
        ;maddr=239.128.16.254;ttl=16
      Via: SIP/2.0/UDP mouse.wonderland.com
      From: Alice <sip:alice@wonderland.com>;tag=1ija
      To: Bob <sip:bob@example.com>
      Call-ID: 602214199@mouse.wonderland.com
      CSeq: 1 INVITE
      Contact: Alice <sip:alice@mouse.wonderland.com>
      Subject: SIP will be discussed, too
      Content-Type: application/sdp
      Content-Length: 187

      v=0
      o=user1 53655765 2353687637 IN IP4 128.3.4.5
      s=Mbone Audio
      t=3149328700 0
      i=Discussion of Mbone Engineering Issues
      e=mbone@somewhere.com
      c=IN IP4 224.2.0.1/127
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
\end{verbatim}

The \header{From} request header above states that the request was
initiated by \host{alice@wonderland.com} and addressed to
\host{bob@example.com} (\header{To} header fields).  The \header{Via}
fields list the hosts along the path from invitation initiator (the last
element of the list) towards the callee.  In the example above, the
message was last multicast to the administratively scoped group
\host{239.128.16.254} with a ttl of \host{16} from the host
\host{sip.example.com}.  The second \header{Via} header field indicates
that it was originally sent from the outbound proxy
\host{mouse.wonderland.com}.  The \header{Request-URI} indicates that
the request is currently being being addressed to
\host{bob@one.example.com}, the local address that the SIP server for
the \host{example.com} domain looked up for the callee.

In this case, the session description is using the Session Description
Protocol (SDP), as stated in the \header{Content-Type} header. 

The header is terminated by an empty line and is followed by a message
body containing the session description.

\subsubsection{Response}

The called user agent, directly or indirectly through proxy servers,
indicates that it is alerting (``ringing'') the called party:

\begin{verbatim}
S->C: SIP/2.0 180 Ringing
      Via: SIP/2.0/UDP sip.example.com;branch=7c337f30d7ce.1
        ;maddr=239.128.16.254;ttl=16
      Via: SIP/2.0/UDP mouse.wonderland.com
      From: Alice <sip:alice@wonderland.com>;tag=1ija
      To: Bob <sip:bob@example.com> ;tag=3141593      
      Call-ID: 602214199@mouse.wonderland.com
      CSeq: 1 INVITE
\end{verbatim}

A sample response to the invitation is given below.  The first line of
the response states the SIP version number, that it is a 200 (OK)
response, which means the request was successful.  The \header{Via}
headers are taken from the request, and entries are removed hop by hop
as the response retraces the path of the request.  A new authentication
field {\MAY} be added by the invited user's agent if required.  The
\header{Call-ID} is taken directly from the original request, along with
the remaining fields of the request message.  The original sense of
\header{From} field is preserved (i.e., it is the session initiator). 

In addition, the \header{Contact} header gives details of the host where
the user was located, or alternatively the relevant proxy contact point
which should be reachable from the caller's host.

\begin{verbatim}
S->C: SIP/2.0 200 OK
      Via: SIP/2.0/UDP sip.example.com;branch=7c337f30d7ce.1
        ;maddr=239.128.16.254;ttl=16
      Via: SIP/2.0/UDP mouse.wonderland.com
      From: Alice <sip:alice@wonderland.com>;tag=1ija
      To: Bob <sip:bob@example.com> ;tag=3141593      
      Call-ID: 602214199@mouse.wonderland.com
      CSeq: 1 INVITE
      Contact: <sip:bob@one.example.com>
\end{verbatim}

The caller confirms the invitation by sending an {\ACK} request to the
location named in the \header{Contact} header:

\begin{verbatim}
C->S: ACK sip:bob@one.example.com SIP/2.0
      Via: SIP/2.0/UDP mouse.wonderland.com
      From: Alice <sip:alice@wonderland.com>;tag=1ija
      To: Bob <sip:bob@example.com> ;tag=3141593      
      Call-ID: 602214199@mouse.wonderland.com
      CSeq: 1 ACK
\end{verbatim}

\subsection{Two-party Call}

For two-party Internet phone calls, the response must contain a
description of where to send the data.  In the example below, Bell calls
Watson.  Bell indicates that he can receive RTP audio codings 0 (PCMU),
3 (GSM), 4 (G.723) and 5 (DVI4).

\begin{verbatim}
C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0
      Via: SIP/2.0/UDP kton.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To: T. Watson <sip:watson@bell-tel.com>
      Call-ID: 662606876@kton.bell-tel.com
      CSeq: 1 INVITE
      Contact: <sip:a.g.bell@kton.bell-tel.com>
      Subject: Mr. Watson, come here.
      Content-Type: application/sdp
      Content-Length: ...

      v=0
      o=bell 53655765 2353687637 IN IP4 128.3.4.5
      s=Mr. Watson, come here.
      e=a.g.bell@bell-tel.com
      t=3149328600 0
      c=IN IP4 kton.bell-tel.com
      m=audio 3456 RTP/AVP 0 3 4 5
      a=rtpmap:0 PCMU/8000
      a=rtpmap:3 GSM/8000
      a=rtpmap:4 G723/8000
      a=rtpmap:5 DVI4/8000

S->C: SIP/2.0 100 Trying
      Via: SIP/2.0/UDP kton.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
      Call-ID: 662606876@kton.bell-tel.com
      CSeq: 1 INVITE
      Content-Length: 0

S->C: SIP/2.0 180 Ringing
      Via: SIP/2.0/UDP kton.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
      Call-ID: 662606876@kton.bell-tel.com
      CSeq: 1 INVITE
      Content-Length: 0

S->C: SIP/2.0 182 Queued, 2 callers ahead
      Via: SIP/2.0/UDP kton.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
      Call-ID: 662606876@kton.bell-tel.com
      CSeq: 1 INVITE
      Content-Length: 0

S->C: SIP/2.0 182 Queued, 1 caller ahead
      Via: SIP/2.0/UDP kton.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
      Call-ID: 662606876@kton.bell-tel.com
      CSeq: 1 INVITE
      Content-Length: 0

S->C: SIP/2.0 200 OK
      Via: SIP/2.0/UDP kton.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To: <sip:watson@bell-tel.com> ;tag=37462311
      Call-ID: 662606876@kton.bell-tel.com
      CSeq: 1 INVITE
      Contact: sip:watson@boston.bell-tel.com
      Content-Type: application/sdp
      Content-Length: ...

      v=0
      o=watson 4858949 4858949 IN IP4 192.1.2.3
      s=I'm on my way
      e=watson@bell-tel.com
      t=3149329600 0
      c=IN IP4 boston.bell-tel.com
      m=audio 5004 RTP/AVP 0 3
      a=rtpmap:0 PCMU/8000
      a=rtpmap:3 GSM/8000
\end{verbatim}

The example illustrates the use of informational status responses. Here,
the reception of the call is confirmed immediately (100), then, possibly
after some database mapping delay, the call rings (180) and is then
queued, with periodic status updates.

Watson can only use PCMU and GSM. Watson will send
audio data to port 3456 at c.bell-tel.com, Bell will send to port 5004
at boston.bell-tel.com.

By default, the media session is one RTP session. Watson will receive
RTCP packets on port 5005, while Bell will receive them on port 3457.

Since the two sides have agreed on the set of media, Bell confirms the
call without enclosing another session description:

\begin{verbatim}
C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0
      Via: SIP/2.0/UDP kton.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
      Call-ID: 662606876@kton.bell-tel.com
      CSeq: 1 ACK
\end{verbatim}

\subsection{Terminating a Call}

To terminate a call, the caller can send a {\BYE} request formatted as
follows:

\begin{verbatim}
C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0
      Via: SIP/2.0/UDP kton.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311
      Call-ID: 3298420296@kton.bell-tel.com
      CSeq: 2 BYE
\end{verbatim}

If the callee wishes to terminate the call, it sends a {\BYE} request
as well. However, this {\BYE} request has the contents of the
\header{To} field from the above message in the \header{From} field,
and the contents of the \header{From} field in the above message in
the \header{To} field.

\subsection{Forking Proxy}

In this example, Bell (\host{a.g.bell@bell-tel.com}) (C), currently
seated at host \host{c.bell-tel.com} wants to call Watson
(\host{t.watson@ieee.org}).  At the time of the call, Watson is logged
in at two workstations, \host{t.watson@x.bell-tel.com} (X) and
\host{watson@y.bell-tel.com} (Y), and has registered with the IEEE proxy
server (P) called \host{sip.ieee.org}.  The IEEE server also has a
registration for the home machine of Watson, at
\host{watson@h.bell-tel.com} (H), as well as a permanent registration at
\host{watson@acm.org} (A).  For brevity, the examples omit the message
bodies containing the session descriptions.

Bell's user agent sends the invitation to the SIP server for the
\host{ieee.org} domain: 

\begin{verbatim}
C->P: INVITE sip:t.watson@ieee.org SIP/2.0
      Via:     SIP/2.0/UDP c.bell-tel.com
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 INVITE
      Contact: a.g.bell@c.bell-tel.com
\end{verbatim}

The SIP server at \host{ieee.org} tries the four addresses in parallel. 
It sends the following message to the home machine:

\begin{verbatim}
P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.1
      Via:     SIP/2.0/UDP c.bell-tel.com
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 INVITE
      Contact: a.g.bell@c.bell-tel.com
\end{verbatim}

This request immediately yields a 404 (Not Found) response, since Watson
is not currently logged in at home:

\begin{verbatim}
H->P: SIP/2.0 404 Not Found 
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.1
      Via:     SIP/2.0/UDP c.bell-tel.com
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>;tag=87454273
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 INVITE
\end{verbatim}

The proxy {\ACK}s the response so that host H can stop retransmitting
it:
\begin{verbatim}
P->H: ACK sip:watson@h.bell-tel.com SIP/2.0
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.1
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>;tag=87454273
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 ACK
\end{verbatim}

Also, P attempts to reach Watson through the ACM server:
\begin{verbatim}
P->A: INVITE sip:watson@acm.org SIP/2.0
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.2
      Via:     SIP/2.0/UDP c.bell-tel.com
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 INVITE
      Contact: a.g.bell@c.bell-tel.com
\end{verbatim}

In parallel, the next attempt proceeds, with an {\INVITE} to X and Y:

\begin{verbatim}
P->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.3
      Via:     SIP/2.0/UDP c.bell-tel.com
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 INVITE
      Contact: a.g.bell@c.bell-tel.com

P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.4
      Via:     SIP/2.0/UDP c.bell-tel.com
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 INVITE
      Contact: a.g.bell@c.bell-tel.com
\end{verbatim}

As it happens, both Watson at X and a colleague in the other lab at host
Y hear the phones ringing and pick up.  Both X and Y return 200s via the
proxy to Bell.

\begin{verbatim}
X->P: SIP/2.0 200 OK
      Via:      SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.3
      Via:      SIP/2.0/UDP c.bell-tel.com
      From:     A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:       T. Watson <sip:t.watson@ieee.org> ;tag=192137601
      Call-ID:  31415@c.bell-tel.com
      CSeq:     1 INVITE
      Contact:  sip:t.watson@x.bell-tel.com

Y->P: SIP/2.0 200 OK
      Via:      SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.4
      Via:      SIP/2.0/UDP c.bell-tel.com
      Contact:  sip:t.watson@y.bell-tel.com
      From:     A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:       T. Watson <sip:t.watson@ieee.org> ;tag=35253448
      Call-ID:  31415@c.bell-tel.com
      CSeq:     1 INVITE
\end{verbatim}

Both responses are forwarded to Bell, using the \header{Via} information. 
At this point, the ACM server is still searching its database.  P can
now cancel this attempt:

\begin{verbatim}
P->A: CANCEL sip:watson@acm.org SIP/2.0
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.2
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 CANCEL
\end{verbatim}

The ACM server gladly stops its neural-network database search and
responds with a 200. The 200 will not travel any further, since P is the
last \header{Via} stop.

\begin{verbatim}
A->P: SIP/2.0 200 OK
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.2
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 CANCEL
\end{verbatim}

In addition, A responds to the original {\INVITE} request with a 487
(Request Terminated):
\begin{verbatim}
A->P: SIP/2.0 487 Request Terminated
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.2
      Via:     SIP/2.0/UDP c.bell-tel.com
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>;tag=0303
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 INVITE
\end{verbatim}
This response terminates at P. P generates an {\ACK}
for the 487:

\begin{verbatim}
P->A: ACK sip:watson@acm.org SIP/2.0
      Via:     SIP/2.0/UDP sip.ieee.org ;branch=3d8a50dbf5a28d.2
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>;tag=0303
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 ACK
\end{verbatim}

Bell gets the two 200 responses from X and Y in short order and sends
and {\ACK} to both directly.  Bell can now keep both call legs or
terminate one with a {\BYE} request. Here, he temporarily keeps both to
determine where the real Watson is located.

\begin{verbatim}
C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0
      Via:      SIP/2.0/UDP c.bell-tel.com
      From:     A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:       T. Watson <sip:t.watson@ieee.org>;tag=192137601
      Call-ID:  31415@c.bell-tel.com
      CSeq:     1 ACK

C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0
      Via:      SIP/2.0/UDP c.bell-tel.com
      From:     A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:       T. Watson <sip:t.watson@ieee.org>;tag=35253448
      Call-ID:  31415@c.bell-tel.com
      CSeq:     1 ACK
\end{verbatim}

After a brief discussion between Bell with X and Y, it becomes clear
that Watson is at X.  (Note that this is not a three-way call; only Bell
can talk to X and Y, but X and Y cannot talk to each other.) Thus, Bell
sends a {\BYE} to Y, which is replied to:

\begin{verbatim}
C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0
      Via:      SIP/2.0/UDP c.bell-tel.com
      From:     A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:       T. Watson <sip:t.watson@ieee.org>;tag=35253448
      Call-ID:  31415@c.bell-tel.com
      CSeq:     2 BYE

Y->C: SIP/2.0 200 OK
      Via:      SIP/2.0/UDP c.bell-tel.com
      From:     A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:       T. Watson <sip:t.watson@ieee.org>;tag=35253448
      Call-ID:  31415@c.bell-tel.com
      CSeq:     2 BYE
\end{verbatim}

\subsection{Redirects}

Replies with status codes 301 (Moved Permanently) or 302 (Moved
Temporarily) specify another location using the \header{Contact} field. 
Continuing our earlier example, the server P at \host{ieee.org} decides
to redirect rather than proxy the request:

\begin{verbatim}
P->C: SIP/2.0 302 Moved temporarily
      Via:     SIP/2.0/UDP c.bell-tel.com
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=3pcc
      To:      T. Watson <sip:t.watson@ieee.org>;tag=72538263
      Call-ID: 31415@c.bell-tel.com
      CSeq:    1 INVITE
      Contact: sip:watson@h.bell-tel.com,
                sip:watson@acm.org, sip:t.watson@x.bell-tel.com,
                sip:watson@y.bell-tel.com 
\end{verbatim}

As another example, assume Alice (A) wants to delegate her calls to Bob
(B) while she is on vacation until July 29th, 1998.  Any calls meant for
her will reach Bob with Alice's \header{To} field, indicating to him
what role he is to play.  Charlie (C) calls Alice (A), whose server
returns:

\begin{verbatim}
A->C: SIP/2.0 302 Moved temporarily
      From: Charlie <sip:charlie@caller.com>;tag=5h7j
      To: Alice <sip:alice@wonderland.com> ;tag=2332462
      Call-ID: 27182@caller.com
      Contact: sip:bob@example.com
      Expires: Wed, 29 Jul 1998 9:00:00 GMT
      CSeq: 1 INVITE
\end{verbatim}

Charlie then sends the following request to the SIP server of the
\host{example.com} domain.  Note that the server at \host{example.com}
forwards the request to Bob based on the \header{Request-URI}.

\begin{verbatim}
C->B: INVITE sip:bob@example.com SIP/2.0
      Via: SIP/2.0/UDP h.caller.com
      From: <sip:charlie@caller.com>;tag=5h7j
      To: sip:alice@wonderland.com
      Call-ID: 27182@caller.com
      CSeq: 2 INVITE
      Contact: sip:charlie@h.caller.com
\end{verbatim}

In the third redirection example, we assume that all outgoing requests
are directed through a local firewall F (``outbound proxy'') at
\host{caller.com}, with Charlie again inviting Alice:

\begin{verbatim}
C->F: INVITE sip:alice@wonderland.com SIP/2.0
      Via: SIP/2.0/UDP h.caller.com
      From: <sip:charlie@caller.com>;tag=5h7j
      To: Alice <sip:alice@wonderland.com>
      Call-ID: 27182@caller.com
      CSeq: 1 INVITE
      Contact: sip:charlie@h.caller.com
\end{verbatim}

The local firewall at \host{caller.com} happens to be overloaded and thus
redirects the call from Charlie to a secondary server S:

\begin{verbatim}
F->C: SIP/2.0 302 Moved temporarily
      Via: SIP/2.0/UDP h.caller.com
      From: <sip:charlie@caller.com>;tag=5h7j
      To: Alice <sip:alice@wonderland.com>
      Call-ID: 27182@caller.com
      CSeq: 1 INVITE
      Contact: <sip:alice@wonderland.com:5080;maddr=spare.caller.com>
\end{verbatim}

Based on this response, Charlie directs the same invitation to the
secondary server \host{spare.caller.com} at port 5080, but maintains the
same \header{Request-URI} as before:

\begin{verbatim}
C->S: INVITE sip:alice@wonderland.com SIP/2.0
      Via: SIP/2.0/UDP h.caller.com
      From: <sip:charlie@caller.com>;tag=5h7j
      To: Alice <sip:alice@wonderland.com>
      Call-ID: 27182@caller.com
      CSeq: 2 INVITE
      Contact: sip:charlie@h.caller.com
\end{verbatim}

\subsection{Negotiation}
\label{sec:negotiation}

An example of a 606 (Not Acceptable) response is:

\begin{verbatim}
S->C: SIP/2.0 606 Not Acceptable
      Via: SIP/2.0/UDP c.bell-tel.com
      From: A. Bell <sip:a.g.bell@bell-tel.com>;tag=3ab6
      To: T. Watson <sip:t.watson@ieee.org> ;tag=7434264 
      Call-ID: 14142@c.bell-tel.com
      CSeq: 1 INVITE
      Warning: 370 "Insufficient bandwidth (only have ISDN)", 
        305 "Incompatible media format", 
        330 "Multicast not available"
      Content-Type: application/sdp
      Content-Length: ...

      v=0
      o=c 3149329138 3149329165 IN IP4 38.245.76.2
      s=Let's talk
      e=t.watson@ieee.org
      t=3149328630 0
      b=CT:128
      c=IN IP4 x.bell-tel.com
      m=audio 3456 RTP/AVP 5 0 7
      a=rtpmap:5 DVI4/8000
      a=rtpmap:0 PCMU/8000
      a=rtpmap:7 LPC/8000
      m=video 2232 RTP/AVP 31
      a=rtpmap:31 H261/90000
\end{verbatim}

In this example, the original request specified a bandwidth that was
higher than the access link could support, requested multicast, and
requested a set of media encodings.  The response states that only 128
kb/s is available and that (only) DVI, PCM or LPC audio could be
supported in order of preference. 

The response also states that multicast is not available. 
In such a case, it might be appropriate to set up a transcoding gateway
and re-invite the user.

\subsection{{\OPTIONS} Request}

A caller Alice can use an {\OPTIONS} request to find out the
capabilities of a potential callee Bob, without ``ringing'' the
designated address.  Bob returns a description indicating that he is
capable of receiving audio encodings PCM mu-law (RTP payload type 0),
1016 (payload type 1), GSM (payload type 3), and SX7300/8000 (dynamic
payload type 99), and video encodings H.261 (payload type 31) and H.263
(payload type 34).

\begin{verbatim}
C->S: OPTIONS sip:bob@example.com SIP/2.0
      Via: SIP/2.0/UDP cat.wonderland.com
      From: Alice <sip:alice@wonderland.com>;tag=1gloo
      To: Bob <sip:bob@example.com>
      Call-ID: 6378@cat.wonderland.com
      CSeq: 1 OPTIONS
      Accept: application/sdp

S->C: SIP/2.0 200 OK 
      From: Alice <sip:alice@wonderland.com>;tag=1gloo
      To: Bob <sip:bob@example.com> ;tag=376364382
      Call-ID: 6378@cat.wonderland.com
      Content-Length: 81
      Content-Type: application/sdp

      v=0
      o=alice 3149329138 3149329165 IN IP4 24.124.37.3
      s=Security problems
      e=bob@example.com
      t=3149328650 0
      c=IN IP4 24.124.37.3
      m=audio 0 RTP/AVP 0 1 3 99
      a=rtpmap:0 PCMU/8000
      a=rtpmap:1 1016/8000
      a=rtpmap:3 GSM/8000
      a=rtpmap:99 SX7300/8000
      m=video 0 RTP/AVP 31 34
      a=rtpmap:31 H261/90000
      a=rtpmap:34 H263/90000
\end{verbatim}
