WDIFF

draft-ietf-sip-rfc2543bis-04.txt --> draft-ietf-sip-rfc2543bis-05.txt

Internet Engineering Task Force SIP WG
Internet Draft Handley/Schulzrinne/Schooler/Rosenberg
draft-ietf-sip-rfc2543bis-04.txt ACIRI/Columbia U./Caltech/dynamicsoft
July 20, Jonathan Rosenberg
dynamicsoft
Henning Schulzrinne
Columbia U.
Gonzalo Camarillo
Ericsson
Alan Johnston
Worldcom
Jon Peterson
Neustar
Robert Sparks
dynamicsoft
Mark Handley
ACIRI
Eve Schooler
AT&T

draft-ietf-sip-rfc2543bis-05.txt
October 26, 2001
Expires: February April 2002

SIP: Session Initiation Protocol

STATUS OF THIS MEMO

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Abstract

The Session Initiation Protocol (SIP) is an application-layer control
(signaling) protocol for creating, modifying and terminating sessions
with one or more participants. These sessions include Internet
multimedia conferences, Internet
telephone calls calls, multimedia distribution and multimedia
distribution. Members in a session can communicate via multicast or
via a mesh of unicast relations, or a combination of these. conferences.

SIP invitations used to create sessions carry session descriptions
which allow participants to agree on a set of compatible media types.
SIP supports user mobility by proxying and redirecting makes use of elements called proxy servers to help route requests
to the user's current location. Users can register their users current
location. SIP is not tied location, assist in firewall traversal, and
provide features to any particular conference control
protocol. users. SIP is designed also provides a registration function
that allows them to be independent upload their current location for use by proxy
servers. SIP runs ontop of the lower-layer several different transport protocol and can be extended with additional capabilities.

Handley/Schulzrinne/Schooler/Rosenberg protocols.

1 Introduction

Various Authors [Page 1]

Internet Draft SIP July 20, October 26, 2001

1 Introduction

1.1

There are many applications of the Internet that require the creation
and management of a session, where a session is considered an
exchange of data between an association of participants. The
implementation of these services is complicated by the practices of
participants; users may move between endpoints, they may be
addressable by multiple names, and they may communicate in several
different media - sometimes simultaneously. Numerous protocols have
been authored that carry various forms of real-time multimedia
session data such as voice, video, or text messages. SIP works in
concert with these protocols by enabling Internet endpoints (called
"user agents") to discover one another and to agree on a
characterization of a session they would like to share. For locating
prospective session participants, SIP relies on an infrastructure of
network hosts (called "proxy servers") to which user agents can send
registrations, invitations to sessions and other requests. SIP is an
agile, general-purpose tool for creating, modifying and terminating
sessions that works independently of underlying transport protocols
and without dependency on the type of session that is being
established.

2 Overview of SIP Functionality

The Session Initiation Protocol (SIP) is an application-layer control
protocol that can establish, modify and terminate multimedia sessions
(conferences) or such as Internet telephony calls. SIP can also invite
participants to unicast and multicast sessions; the initiator already existing sessions. A SIP entity issuing an
invitation for an already existing session does not necessarily have
to be a member of the session to which it is inviting. Media and participants can be
added to (and removed from) 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 which supports
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 [1] - users as they move. Personal mobility is
based on the use of a unique personal identity (i.e., personal
number)." [1]. Personal mobility complements terminal mobility, i.e.,
the ability to can maintain communications when moving a single end
system from one subnet to another. externally
visible identifier (SIP URI) regardless of their network location.

SIP supports five facets of establishing and terminating multimedia
communications:

User location: determination of the end system to be used for
communication;

User capabilities: determination of the media and media
parameters to be used;

User availability: determination of the willingness of the
called party to engage in communications;

Call

User capabilities: determination of the media and media
parameters to be used;

Session setup: "ringing", establishment of call session parameters at
both called and calling party;

Call

Various Authors [Page 2]

Internet Draft SIP October 26, 2001

Session handling: including transfer and termination of calls.
sessions, modifying session parameters, and invoking
services.

SIP is designed as part not a vertically integrated communications system. SIP is
rather a component of the overall IETF multimedia data and control
architecture currently incorporating which incorporates protocols such as RSVP (RFC 2205 [2])
for reserving network resources, the real-time transport protocol
(RTP) (RFC 1889 [3]) for transporting real-time data and providing
QOS feedback, the real-time streaming protocol (RTSP) (RFC 2326 [4])
for controlling delivery of streaming media, the session announcement
protocol (SAP) [5] for advertising

Handley/Schulzrinne/Schooler/Rosenberg [Page 2]

Internet Draft SIP July 20, 2001 multimedia sessions via multicast
and the session description protocol (SDP) (RFC 2327 [6]) for
describing multimedia sessions. Therefore, SIP should be used in
conjunction with other protocols in order to provide complete
services to the users. However, the basic 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 provide services. SIP rather provides primitives that
can be used to introduce conference control protocols. implement different services. For example, SIP
does not allocate multicast addresses and can
locate a user and deliver an opaque object to his current location.
If this primitive is used to deliver a session description written in
SDP, for instance, the parameters of a session can be agreed between
endpoints. If the same primitive is used to deliver a photo of the
caller as well as the session description, a "caller ID" service can
be easily implemented. As this example shows, a single primitive is
typically used to provide several different services. Consequently,
generality is more important than efficiency when designing SIP
primitives.

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 initiate a session that uses some other
conference control protocol. SIP does not allocate multicast
addresses and does not reserve network resources.

1.2

3 Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and
indicate requirement levels for compliant SIP implementations.

1.3

4 Overview of SIP Operation

This section explains will introduce the basic protocol functionality and operation.
Terms are defined more precisely in Section 1.4. In SIP, protocol
participants are identified by SIP URLs, described in Section 1.4.1. operations of the SIP protocol
using simple examples. Note that this section is a request-response protocol, with requests sent by clients and
received by servers. A single implementation typically combines both
client tutorial in nature
and server functionality. SIP requests can be sent using does not contain any
reliable or unreliable protocol, including UDP, SCTP [8] normative statements.

Various Authors [Page 3]

Internet Draft SIP October 26, 2001

The first example will show the basic functions of SIP: location of
an end point, signaling a desire to communicate, negotiation of
session parameters to establish the session, and TCP.
Protocol operation is largely independent teardown of the lower-layer
transport protocol.

This specification defines six SIP request methods: INVITE (Section
5.1) initiates sessions, ACK (Section 5.1.1) confirms
session
establishment, OPTIONS (Section 8) requests information about
capabilities, BYE (Section 6) terminates once established.

Figure 1 shows a sessions, CANCEL (Section
5.2) cancels typical example of a pending session SIP message exchange between
two users, Alice and Bob. (Each message is labeled with the letter
"F" and REGISTER (Section 7) allows a
client to bind number for reference by the text.) In this example, Alice
uses a permanent SIP URL application on her PC (referred to as a temporary softphone) to call
Bob on his SIP URL reflecting phone over the current network location. Internet. Also shown are two SIP requests proxy
servers which act on behalf of Alice and responses consists 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 1.

Alice "calls" Bob using his SIP identity, a request (or status) line, a
number type of header lines and Uniform Resource
Identifier (URI) called a message body (Section 3). SIP requests can be sent directly from a user agent client to URI and defined in Section 21.1. It has
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 form to SMTP MTAs.

User agents send requests either directly to the address indicated in 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 URI or to service provider (which can be
an enterprise, retail provider, etc). Alice also has a designated proxy ("outbound proxy"), independent

Handley/Schulzrinne/Schooler/Rosenberg [Page 3]

Internet Draft SIP July 20, 2001 URI of the destination address. The current destination
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.

SIP is
carried in the Request-URI. Each proxy can forward the request based on local policy and information contained in the SIP request. The
proxy MAY rewrite the an HTTP-like request/response transacton model. Each
transaction consists of a request URI. A proxy MAY also forward that invokes a particular "Method",
or function, on the
request to another designated proxy regardless of server, and at least one response. In this
example, the transaction begins with Alice's softphone sending an
INVITE request URI.
For example, a departmental proxy could forward all authorized
requests addressed to Bob's SIP URI. INVITE is an example of a corporate-wide proxy
SIP method which then forwards it to the
proxy operated by specifies the Internet service provider, which finally routes action that the request based on requestor (Alice)
wants the server (Bob) to take. The INVITE request URI.

Proxies MAY modify any part contains a number
of the SIP message that header fields. Header fields 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 additional named attributes which
provide additional information about a message. The ones present in
an INVITE include a unique identifier for the user agent wants to contact call, the user
sip:alice@example.com, it sends destination
address, Alice's address, and information about the request type of session
that Alice wishes to establish with Bob. The INVITE (message F1 in
Figure 1) might look like this:

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 10.1.3.3:5060
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.1.3.3
CSeq: 314159 INVITE
Contact: <sip:alice@10.1.3.3>
Content-Type: application/sdp

Various Authors [Page 4]

Internet Draft SIP October 26, 2001

atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F3 | |
| 100 Trying F2 |--------------->| INVITE F5 |
|<---------------| 100 Trying F4 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |

Figure 1: SIP session setup example with SIP trapezoid

Contact-Length: 142

(Alice's SDP not shown)

The first line of the server handling text-encoded message contains the example.com domain (Section 1.4.2). If that host acts as method name
(INVITE). The lines which follow are a proxy
server, it looks up whether it has list of header fields. This
example contains a mapping from alice@example.com
to another address. If so, it substitutes that address, say
alice@sales.example.com, into minimum required set. The headers are briefly
described below:

Via contains the Request-URI IP address (10.1.3.3), port number (5060), and then sends the
request
transport protocol (UDP) on which Alice is expecting to the server for the sales.example.com domain. Any server
can also return receive
responses to this request.

Various Authors [Page 5]

Internet Draft SIP October 26, 2001

To contains a response indicating display name (Bob) and a different destination to be
tried by the upstream client or indicating SIP URI (sip:bob@biloxi.com)
that the request cannot be
forwarded.

Typically, only the first request within was originally directed towards.

From also contains a call traverses all
proxies, while subsequent requests are exchanged directly between
user agents. However, display name (Alice) and a proxy can indicate SIP URI
(sip:alice@atlanta.com) that it wants to remain
in indicate the request path via a Record-Route (Section 10.34) header field.

1.4 Definitions originator of the request.
This specification uses header field also has a number of terms to refer tag parameter which contains a
pseudorandom string (1928301774) which was added to the roles
played URI by participants in SIP communications. The definitions of
client, server and proxy are similar to those the
softphone. It is used for identification purposes.

Call-ID contains a globally unique identifier for this call,
generated by the Hypertext
Transport Protocol (HTTP) (RFC 2616 [9]). The terms and generic
syntax combination of URI a pseudorandom string and URL are defined in RFC 2396 [10]. the
softphone's IP address. The following
terms have special significance for SIP.

Back-To-Back User Agent: Also known as a B2BUA, this is a
logical entity that receives an invitation, combination of the To, From, and acts as Call-ID
completely define a
UAS to process it. In order peer-to-peer SIP relationship betwee Alice and
Bob, and is referred 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 "dialog".

CSeq or Command Sequence contains an integer and must participate in all requests for a call.
Since it method name. The
CSeq number is purely a concatenation of other logical
functions, no explicit definitions are needed incremented for its

Handley/Schulzrinne/Schooler/Rosenberg [Page 4]

Internet Draft SIP July 20, 2001

behavior.

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 10.12), each new request, and is created when a user
agent sends an INVITE request. This INVITE request may
generate multiple acceptances, each of traditional
sequence number.

Contact contains a SIP URI which are part of
the same call (but different call legs). Furthermore, if represents a
user is invited direct route to the same multicast session by several
people, each reach
or contact Alice, usually composed of these invitations will be a unique call. In
a multiparty conference unit (MCU) based call-in
conference, each participant uses a separate call username at an IP address.
While the Via header field is used to invite
himself tell other elements where to
send the MCU.

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 response, the Contact header field tells other elements
where to send future requests for this dialog.

Content-Type contains a successful response. It is
identified by description of the combination message body (not shown).

Content-Length contains an octet (byte) count of the Call-ID message body.

The complete set of SIP header field,
the local address fields is defined in Section 22.

The details of the participant, and session, type of media, codec, sampling rate, etc.
are not described using SIP. Rather, the remote
address body of a SIP message
contains a description of the session, encoded in some other participant. For the caller, the local
address protocol
format. One such format is Session Description Protocol (SDP) [6].
This SDP message (not shown in the From field of the INVITE, and example) is carried by the remote
address SIP
message in an analogous way that a document attachment is carried by
an email message, or a web page is carried in an HTTP message.

Since the To field softphone has no knowledge of Bob's exact location, or how
to locate the 200 class response. For the
callee, SIP server in the local address is biloxi.com domain, the To field of softphone
sends the 200 class
response INVITE to the INVITE, and the remote SIP server that serves Alice's domain,
atlanta.com. The IP address is the From
field of the INVITE. atlanta.com SIP URIs are compared according to
Section 2.1, non-SIP URIs according to Section 2.2. Within
the same Call-ID, requests with From A and To value B
belong to the same call leg as the requests server could have
been configured in the opposite
direction, i.e., From B and To A.

Call Stateful: A proxy is said to be call stateful when Alice's softphone, or it
retains state that persists could have been
discovered by DHCP, 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.

Client: An application program that sends example.

The atlanta.com SIP requests. Clients
may or may not interact directly with a human user. User
agents and proxies contain clients (and servers).

Conference: A multimedia session (see below), identified by server is a
common session description. A conference can have zero or
more members and includes the cases type of a multicast
conference, a full-mesh conference and a two-party
"telephone call", as well SIP server known as combinations of these. Any
number of calls can be used to create a conference.

Downstream: Requests sent in the direction from the caller to

Handley/Schulzrinne/Schooler/Rosenberg proxy
server. A proxy server receives SIP requests and forwards them on

Various Authors [Page 5] 6]

Internet Draft SIP July 20, October 26, 2001

behalf of the callee (i.e., user agent client to user agent server).

Final response: A response that terminates requestor. In this example, the proxy server receives
the INVITE request and generates a SIP transaction, as
opposed 100 Trying response which is sent
back to a provisional Alice's softphone. The 100 Trying response indicates that does not. All 2xx,
3xx, 4xx, 5xx the
INVITE has been received and 6xx responses are final.

Initiator, calling party, caller: The party initiating a session
invitation. Note that the calling party does not have proxy is working on her behalf
to be
the same as the one creating the conference. A caller
retains this role for try to route the duration of a call.

Invitation: A request sent INVITE to a user (or service) requesting
participation the destination. Responses in a session. A successful SIP invitation
consists of two transactions: an INVITE request use
a numerical three digit code followed by
an ACK request.

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.

Isomorphic request or response: Two requests or responses are
defined to be isomorphic for the purposes of this document
if they have descriptive phrase. This
response contains the same values for the Call-ID, To, From From, Call-ID, and CSeq header fields. In addition, isomorphic requests have as the INVITE,
which allows Alice's softphone to correlate this response to have the same Request-URI and sent
INVITE. The atlanta.com proxy server locates the same top-most Via
header.

Location server: See location service.

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 at
biloxi.com, possibly by
location servers. Location servers MAY be part of performing a SIP
server, but DNS (Domain Name Service) lookup
to find the manner in which a SIP server requests
location services is beyond which serves the scope of this document.

Outbound proxy: A proxy that biloxi.com domain. This is located near
described in Section 24. As a result, it obtains the originator IP address of
requests. It receives all outgoing requests from a
particular UAC, including those requests whose Request-URLs
identify a host other than
the outbound proxy. The outbound biloxi.com proxy sends these requests, after any local processing, to
the address indicated in the Request-URI. (All other proxy
servers are simply referred as server and forwards, or proxies, not inbound
proxies.)

Handley/Schulzrinne/Schooler/Rosenberg [Page 6]

Internet Draft SIP July 20, 2001

Parallel search: In a parallel search, a proxy issues several
requests to possible user locations upon receiving an
incoming request. Rather than issuing one the INVITE
request and then
waiting for there. Before forwarding the final response before issuing request, the next
request as atlanta.com proxy
server adds an additional Via header field which contains its own IP
address (the INVITE already contains Alice's IP address in a sequential search , a parallel search
issues requests without waiting for the result of previous
requests.

Provisional response: A first
Via). The biloxi.com proxy server receives the INVITE and responds
with a 100 Trying response used by back to the Atlanta.com proxy server to
indicate
progress, but that does not terminate a SIP transaction.
1xx responses are provisional, other responses are
considered final.

Proxy, proxy server: An intermediary program that acts as both a
server it has received the INVITE and a client for is processing 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
request. The proxy interprets, and, if necessary, rewrites a
request message before forwarding it.

Proxy servers are, for example, used to route
requests, enforce policies, control firewalls.

Redirect server: A redirect server is consults a server that accepts database, generically called a
SIP request, maps
location service, which contains the current IP address into zero or more new
addresses and returns these addresses to of Bob. (We
shall see in the client. Unlike
a next section how this database can be populated.)
The biloxi.com proxy server , it does not initiate adds another Via header with its own SIP request.
Unlike a user agent server , IP
address to the INVITE and proxies it does to Bob's SIP phone.

Bob's SIP phone receives the INVITE and begins to alert Bob to the
incoming call from Alice so that Bob can decide whether or not accept calls.

Registrar: A registrar is to
answer the call - i.e. Bob's phone rings. Bob's SIP phone sends an
indication of this in a server that accepts REGISTER
requests. A registrar 180 Ringing response. This response is typically co-located with a routed
back thorough the two proxies in the reverse direction. Each proxy
or redirect server
uses the Via header to figure out where to send the response, and MAY make
removes its information available
through own address from the location server.

Regular Transaction: A regular transaction is any transaction
with top. As a method other than result, although DNS and
location service lookups were required to route the initial INVITE, ACK,
the 180 Ringing response can be returned to the caller without
lookups, or CANCEL.

Ringback: Ringback is without state being maintained in the signaling tone produced by proxies. This also
has the calling
client's application indicating desirable property that a called party is
being alerted (ringing).

Server: A server is an application program each proxy that accepts requests
in order to service requests and sends back sees the INVITE will
also see all responses to
those requests. Servers are either proxy, redirect the INVITE.

When Alice's softphone receives the 180 Ringing response, it passes
this information to Alice, perhaps using an audio ringback tone, or user
agent servers
just by displaying or registrars.

Session: From the SDP specification: "A multimedia session is flashing a

Handley/Schulzrinne/Schooler/Rosenberg [Page 7]

Internet Draft SIP July 20, 2001

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 [6]) (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, message on Alice's screen.

In this example, Bob decides to answer the same session. If
SDP is used, a session is defined by the concatenation of
the user name , session id , network type , address type
and address elements in call. When he picks up the origin field.

(SIP) transaction: A
handset his 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 phone sends a final (non-1xx) 200 OK response sent from the server to indicate that the client. A transaction
is identified by the CSeq sequence number (Section 10.20)
within a single
call leg. The ACK request has been answered. The 200 OK contains a message body containing
the same
CSeq number as SDP media description of the corresponding INVITE request, but
comprises a transaction type of its own.

Spiral: A spiral session that Bob is willing
to establish with Alice. As a SIP request which result, there is routed to a proxy,
forwarded onwards, two-phase exchange
of SDP messages; Alice sent one to Bob, and Bob sent one back to

Various Authors [Page 7]

Internet Draft SIP October 26, 2001

Alice. This two-phase exchange provides basic negotiation
capabilities, and arrives once again at that proxy,
but this time, with a Request-URI that differs from the
previous arrival. A spiral is based on a simple offer/answer model, If Bob did
not wish to answer the call, or was busy on another call, an error condition,
unlike a loop.

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.

Stateful Proxy: A logical entity that maintains state
information for the duration would have been sent instead of a SIP transaction. Also
known as a transaction stateful proxy. the 200 OK, which would have
resulted in no media session being established. The behavior complete list of a
stateful proxy
SIP response codes is further defined in Section 17.3. A
stateful proxy is 23. The 200 OK (message F9 in Figure
1) might look like this:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.2.1.1:5060;branch=4b43c2ff8.1
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=77ef4c2312983.1
Via: SIP/2.0/UDP 10.1.3.3:5060
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.1.3.3
CSeq: 314159 INVITE
Contact: <sip:bob@10.4.1.4>
Content-Type: application/sdp
Contact-Length: 131

(Bob's SDP not shown)

The first line of the same as a call stateful proxy.

Upstream: Responses sent in response contains the direction response code (200) and
the reason phrase (OK). The remaining lines contain header fields.
The Via header fields, To, From, Call- ID, and CSeq are all copied
from the user agent
server to INVITE request. (Note that there are three Via headers -
one added by Alice's SIP phone, one added by the user agent client.

URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [11].

User agent client (UAC): A user agent client is a logical entity atlanta.com proxy,
and one added by the biloxi.com proxy.) Also note that initiates a Bob's SIP transaction with
phone has added a request. tag parameter to the To header field. This role
lasts only for tag will
be incorporated by both User Agents into the duration of that transaction. In other
words, if dialog and will be
included in all future requests and responses in this call. The
Contact header field contains a piece of software initiates URI at which Bob can be directly
reached at his SIP phone. The Content-Type and Content-Length refer
to the not shown message body which contains Bob's SDP media
information.

In additon to DNS and location service lookups shown in this example,
proxy servers can make arbitrarily complex "routing decisions" in
order to decide where to send a request, it acts
as request. For example, if Bob's SIP
phone returned a UAC for 486 Busy Here response, the duration of that request. If it receives biloxi.com proxy server
could proxy the INVITE to Bob's voicemail server. A proxy server can
also send an INVITE to a
request later on, it takes on number of locations at the role same time. This
type of a User Agent

Handley/Schulzrinne/Schooler/Rosenberg parallel search is known as "forking".

In this case, the 200 OK is routed back through the two proxies and

Various Authors [Page 8]

Internet Draft SIP July 20, October 26, 2001

Server for

is received by Alice's softphone which then stops the processing of ringback tone
and indicates that transaction.

User agent server (UAS): A user agent server the call has been answered. Finally, an
acknowledgement message, ACK, is a logical entity
that responds sent by Alice to a SIP request, generally acting on behalf Bob to confirm the
reception of some user. The the final response accepts, rejects or redirects (200 OK). Note that in this example,
the request. This role lasts only for ACK is sent directly from Alice to Bob, bypassing the duration of that
transaction. In other words, if a piece of software
responds two
proxies. This is due to a request, it acts as a UAS for the duration of fact that request. If it generates a request later on, it takes
on through the role of a User Agent Client for INVITE/200 OK
exchange, the processing of
that transaction.

User agent (UA): A logical entity which acts as both a user
agent client and two SIP user agent server for agents have learned each other's IP
address through the duration of a
call.

An application program MAY be capable Contact header fields, something which was not
known when the initial INVITE was sent. The lookups performed by the
two proxies are no longer needed, so they drop put 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 the call flow.
This completes the INVITE/200/ACK three way handshake used to conferences
establish SIP sessions, and as a user agent server to accept
invitations. The role is the end of UAC the transaction. Full
details on session setup is in Section 13.

Alice and UAS as well as proxy Bob's media session has now begun, and redirect
servers are defined on a request-by-request basis. For example, the
user agent initiating a call acts as a UAC when they begin sending
media packets using the initial
INVITE request and as a UAS when receiving a BYE request from format agreed to in the
callee. Similarly, exchange of SDP. In
general, the same software can act as a proxy server for
one request and as end-to-end media packets will take a redirect server for different path from
the next request.

Proxy, redirect, location and registrar servers defined above are
logical entities; implementations MAY combine them into a single
application program. The properties of the different SIP server types
are summarized in Table 1.

property redirect proxy user agent registrar
server server server
__________________________________________________________________
also acts as a SIP client no yes no no
inserts Via header no yes no no
accepts ACK yes yes yes no

Table 1: Properties of signaling messages.

During the different SIP server types

1.4.1 SIP Addressing

The "objects" addressed by SIP are users at hosts, identified by a
SIP URL. The SIP URL takes a form similar to a mailto or telnet URL,
i.e., user@host. The user part is a user name or a telephone number.

Handley/Schulzrinne/Schooler/Rosenberg [Page 9]

Internet Draft SIP July 20, 2001

The host part is session, either a domain name or a numeric network address.
See section 2 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, Alice 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 Bob may decide to change the
characteristics of several end systems), the first available person from media session. This is accomplished by sending
a group
of individuals or re-INVITE containing a whole group. The form of new media description. If the address, for
example, sip:sales@example.com , change is not sufficient, in general,
acceptable to
determine the intent of the caller.

If other party, a user or service chooses to be reachable at an address that 200 OK is
guessable from the person's name and organizational affiliation, the
traditional method of ensuring privacy by having an unlisted "phone"
number sent which 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.

1.4.2 Locating a SIP Server

The Request-URI is determined according
responded to with an ACK. This re-INVITE will reference the rules in Section 16
and can be derived from either existing
dialog so the Route, Contact or To header
fields.

When a client wishes other party knows that it is to send modify an existing
session instead of establishing a request, new session. If the client either sends it to change is not
acceptable, an error response, such as a locally configured SIP proxy server, 406 Not Acceptable response
is sent, which also receives an ACK. However, the so-called outbound proxy ,
independent failure of the Request-URI, or sends it to re-
INVITE does not cause the IP address and
port corresponding existing call to fail - the Request-URI. The outbound proxy can be
configured by any mechanism, including DHCP [12] and can be specified
either as a set session
continues using the previously negotiated characteristics. Full
details on session modification is in Section 14.

At the end of parameters such as network address or host name,
protocol port the call, Bob disconnects (hangs up) first, and transport protocol, or as
generates a SIP URI.

If the Request-URI BYE message. This BYE is used, the client needs routed directly to determine Alice's
softphone, again bypassing the
protocol, port and IP address proxies. Alice confirms receipt of the
BYE with a server to 200 OK response, which to send terminates the
request. A client SHOULD follow session and the steps below to obtain BYE
transaction. Note that no ACK is sent - an ACK is only sent in
response to a response to an INVITE request. The reasons for this
information.

Clients MUST re-run the above selection algorithm, re-drawing any
random numbers involved, once per transaction rather than
special handling for each
request, i.e., requests within the same transaction MUST INVITE will be sent discussed later, but relate to
the same network address. Thus, reliability mechanisms in SIP, the same address is used length of time it can take for the
request, any retransmissions, any associated CANCEL requests
a ringing phone to be answered, and ACK
requests for non-2xx responses. However, ACKs for 2xx responses use

Handley/Schulzrinne/Schooler/Rosenberg 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 is in Section 15.

Full details of all the messages shown in the example of Figure 1 are
shown in Section 25.2.

Various Authors [Page 10] 9]

Internet Draft SIP July 20, October 26, 2001

another iteration of the selection algorithm. (Indeed, in many

In some cases,
they it may have different request URIs.)

A stateless proxy can accomplish this, be useful for example, by using the
modulo N of a hash of proxies in the Call-ID value or some other combination of
transaction-identifying headers as SIP signaling path
see all the uniform random number
described in messaging between the weighting algorithm of RFC 2782. Here, N is two endpoints for the sum duration of weights within
the priority class.

A client SHOULD be able to interpret explicit network notifications
(such as ICMP messages) which indicate that a server is not
reachable, rather than relying solely on timeouts. (For socket-based
programs: session. For TCP, connect() returns ECONNREFUSED example, if the client
could not connect to a biloxi.com proxy server at that address. For UDP, the socket
needs to be bound wished to
remain in the destination address using connect() rather
than sendto() or similar so that a second write() or send() fails
with ECONNREFUSED if there is no server listening) If SIP messaging path beyond the client
finds initial INVITE, it would
add to the server is not reachable at INVITE a particular address, it SHOULD
behave required routing header field known as if it had received Record-
Route containing a 400-class error response to that
request.

The client tries URI which resolves to find one or more addresses for the SIP server proxy. This information
would be received by
querying DNS. If a step elicits no addresses, the client continues to
the next step. However if a step elicits one or more addresses, but
no both Bob's SIP server at any of those addresses responds, then the client
concludes the server is down phone and does not continue on (due to the next
step.

If Record-
Route header field being passed back in the client is configured with 200 OK) Alice's softphone
and stored for the address duration of an outbound proxy, the parameters of dialog. This would then result in
the outbound proxy, including transport protocol ACK, BYE, and port, become 200 OK to the destination used below.

If there is no outbound proxy, BYE being received and proxied by the destination
biloxi.com proxy server. Each proxy can independently decide to
receive subsequent messaging, and that messaging will go through all
proxies that elected to receive it. A common use of this capability
is the Request-URI.
The destination address in firewall traversal or mid-call feature implementation.

Registration is another common operation in SIP. Registration is one
way in which the maddr parameter if it exists and biloxi.com server can learn the
host element if not. current location of
Bob. Upon initialization, and at periodic intervals, Bob's SIP phone
sends REGISTER messages a server in the biloxi.com domain known as a
SIP registrar. The transport protocol REGISTER messages associate Bob's SIP URL
(sip:bob@biloxi.com) with the machine he is currently logged in at
(conveyed as a SIP URL in the transport
parameter. Contact header). The registrar writes
this association, also called a binding, to a database, called the
location service identifier , where it can be used by the proxy in the
biloxi.com domain. Often, a registrar server for DNS SRV records [13] a domain is "_sip".

1. If co-
located with the destination address proxy for that domain. It is an important concept
that the distinction between types of SIP servers are logical, not
physical.

Bob is not limited to registering from a numeric IP address, single device. For example,
both his SIP phone at home and the
client contacts one in the server office could send in
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 given address same time.

The location service is just an abstract concept. It generally
contains information that allows a proxy to input a URI and get back
a translated URI that tells the
port number specified in proxy where to send the SIP-URI or, if request.
Registrations are one way to create this information, but not specified, the default port (5060).

If the destination specifies a protocol,
only way. Arbitrarily complex mapping functions can be programmed, at
the client
contacts discretion of the server using administrator.

Finally, it is important to note that protocol. If no protocol in SIP, registration is
specified, the client first tries UDP. If attempt fails, 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, challenge/response mechanism, or
if the client does not support UDP but supports other

Handley/Schulzrinne/Schooler/Rosenberg
using a lower layer scheme as discussed in Section 20.

Various Authors [Page 11] 10]

Internet Draft SIP July 20, October 26, 2001

protocols, it tries those protocols in some
implementation-defined order.

The client then skips the remaining steps.

2. If complete set of SIP message details for this registration example
is in Section 25.2.

Additional operations in SIP include querying for the destination specifies no port number capabilities of
a SIP server or port number
5060, client using OPTIONS, and canceling a pending request
using CANCEL will be introduced in later sections.

5 Structure of the transport Protocol

The SIP protocol determines the use is structured as a layered protocol, which means
that its behavior is described in terms of one a set of
the following three rules:

- If the destination does not specify fairly
independent processing stages, with only a transport protocol,
DNS SRV records are retrieved according to RFC 2782 [13]. loose coupling between
each stage. The results structuring of the query or queries are merged and
ordered based on priority, keeping only records with
transport protocols that into layers is for the client supports. Then,
purpose of presentation and conciseness; it allows the
searching technique outlined grouping of
functions common across elements into a single place. It does not
dictate an implementation in RFC 2782 [13] any way. When we say that an element
"contains" a layer, that means it is used compliant to
select servers in order. Server selection across requests
is independent of previous choices, except as noted above
for stateless proxies. Message length or other request
properties do not influence the server selection. The
client attempts to contact each server in the order
listed, at the port number specified in the SRV record.
If none set of rules
defined by that layer.

Not every element specified by the servers can be contacted, protocol contains every layer.
Furthermore, the client gives
up. If there are no SRV records (with any transport
protocol), DNS address records elements specified by SIP are used, logical elements, not
physical ones. A physical realization can choose to act as described
below.

- If different
logical elements, perhaps even on a transport transaction by transaction basis.

The lowest layer of the SIP protocol is specified its syntax and this protocol encoding. Its
encoding is
supported by the client, specified using a BNF. The complete BNF is specified in
Section 26. However, a basic overview of the procedure structure of a SIP
message can be found in Section 7. This section introduces enough of
an understanding of the paragraph
above is used, limited format of a SIP message to DNS resource records with the
transport protocol specified in facilitate
understanding the SIP-URI.

- If remainder of the transport protocol specified protocol.

The next higher layer is not supported by
the client, the transport layer. This layer defines how
a client gives up.

If there are no SRV records, takes a request, and physically sends it over the network,
and how a response is sent by a server, and then received by a
client. All SIP elements contain a transport layer. The transport
layer is described in Section 19.

The next step applies.

3. If higher layer is the destination specifies a port number other than 5060
or if there transaction layer. Transactions are no SRV records, the a
fundamental component of SIP. A transaction is a request, sent by a
client queries transaction (using the DNS transport layer), to a server for address records for the destination address.
Address records include A RR's, AAAA RR's, or other similar
records, chosen according
transaction, along with all responses to that request sent from the client's network protocol
capabilities.

If the DNS
server returns no address records, the client
gives up. If there are address records, the same rules as
in step 2 apply.

Clients MUST NOT cache query results except according transaction back to the rules client. The transaction layer handles
retransmissions, matching of responses to requests, and timeouts. Any
task that a UAC wishes to accomplish takes place using a series of
transactions. Discussion of transactions can be found in

Handley/Schulzrinne/Schooler/Rosenberg Section 17.
User agents contain a transaction layer, as do stateful proxies.
Stateless proxies do not contain a transaction layer.

Various Authors [Page 12] 11]

Internet Draft SIP July 20, October 26, 2001

RFC 1035 [14].

The results transaction layer has a client component (referred to as a client
transaction), and a server component (referred to as a server
transaction), each of the DNS lookup operation do not, in general, lead which are represented by an FSM that is
constructed to process a
modification particular request. The layer on top of the Request-URI.

A proxy
transaction layer is free called the transaction user (TU), of which there
are several types. When a TU wishes to modify send a request, it creates a
client transaction instance and passes it the Request-URI request, along with the
destination IP address, port, and transport to any value
desired, but send the DNS lookups are usually based on request to.

SIP provides the
Request-URI obtained from ability for a location server.

If transaction to be canceled by the DNS time-to-live value exceeds
client which initiated it. When a few minutes,
servers generating client cancels a large number of transaction, it
requests are probably
well advised to retry failed servers every few minutes.

1.4.3 SIP Transaction

Once that the host part has been resolved server give up on further processing, revert to a SIP server, the client
sends one or more SIP requests to
state that server and receives one or
more responses from the server. A request (and its retransmissions)
together with existed before the responses triggered by that request make up transaction was initiated, and generate
a SIP
transaction. All responses specific error response to that transaction. This is done with a request contain
CANCEL request, which constitutes its own transaction, but references
the same values transaction to be cancelled. Cancellation is described in Section
9.

There are several different types of transaction users. A UAC
contains a UAC core, a UAS contains a UAS core, and a proxy contains
a proxy core. The behavior of the Call-ID, CSeq, To, UAC and From fields (with UAS cores depend largely on
the possible addition method. However, there are some common rules for all methods.
These rules are captured in Section 8. The primarily deal with
construction of a tag request, in the To field (section 10.43)). This allows responses to be
matched with requests. The ACK request confirming case of a UAC, and processing of
that request, and generation of a response, in the receipt case of a UAS.

UAC and UAS core behavior for the REGISTER method is described in
Section 10. Registrations play an
INVITE response important role in SIP. In fact, a
UAS that handles a REGISTER is not part of the transaction since it may traverse given a different set of hosts.

If special name - a reliable stream protocol registrar -
and it is used, request described in that section.

UAC and responses within UAS core behavior for the OPTIONS method, used for
determining the capabilities of a
single SIP transaction UAC, are carried over the same connection (see described in Section 14). Several SIP 11.

Certain other requests from are sent within a dialog peer-to-peer SIP
relationship between a two user agents that persists for some time.
The dialog facilitates sequencing of messages between the same client user
agents, and proper routing of requests between both them. One way to the same
server MAY use the same connection or MAY use
setup a new connection for
each request.

If dialog is with the INVITE method. When a client UAC sends the request via a unicast datagram protocol such as
UDP, the receiving user agent directs the response according to request
that is within the
information contained in context of a dialog, it follows the Via header fields (Section 10.46). Each
proxy server common UAC
rules as discussed in Section 8, but also the forward path of the request forwards rules for mid-dialog
requests. Section 12 discusses dialogs, and presents the response
using these Via header fields, as described procedures
for their construction, and maintenance, in detail addition to construction
of requests within a dialog.

The most important method in Sections
10.46.3 and 10.46.4. For datagram protocols, reliability SIP is achieved
using retransmission (Section 14).

1.4.4 Initiating the INVITE method, which is used
to establish a Session session between participants. A session is initiated with a
collection of participants, and streams of media between them, for

Various Authors [Page 12]

Internet Draft SIP October 26, 2001

the INVITE request. A successful purposes of communication. Section 13 discusses how sessions are
initiated, resulting in one or more SIP
invitation consists dialogs. Section 14 discusses
how characteristics of two requests, that session are modified, through the use of
an INVITE followed by ACK. The
INVITE (Section 5.1) request asks the callee to join a particular
conference or establish within a two-party conversation. After the callee
has agreed to participate in the call, the caller confirms that it

Handley/Schulzrinne/Schooler/Rosenberg [Page 13]

Internet Draft SIP July 20, 2001

has received that response by sending an ACK (Section 5.1.1) request.

The INVITE request typically contains dialog. Finally, section 15 discusses how
a session description, for
example written in SDP (RFC 2327 [6]) format, that provides the
called party is terminated.

The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
entirely with enough information to join the session. For
multicast sessions, UA core. Section 16 discusses the session description enumerates proxy element,
which facilitates routing of messages between user agents.

6 Definitions

This specification uses a number of terms to refer to the media
types roles
played by participants in SIP communications. The definitions of
client, server and formats that proxy are allowed to be distributed similar to that session.
For a unicast session, the session description enumerates those used by the media
types Hypertext
Transport Protocol (HTTP) (RFC 2616 [8]). The terms and formats that the caller generic
syntax of URI and URL are defined in RFC 2396 [9]. The following
terms have special significance for SIP.

Back-to-Back user agent: A back-to-back user agent (B2BUA) is willing to use a
logical entity that receives a request, and where processes it
wishes the media data to be sent. as
a UAS. In either case, if the callee
wishes order to accept determine how the call, request should be
answered, it responds to the invitation by returning acts as a similar description listing UAC and generates requests. Unlike a
proxy server, it maintains dialog state, and must
participate in all requests sent on the media dialogs it wishes to use. For has
established. Since it is a
multicast session, the callee SHOULD only return concatenation of a session
description if it UAC and UAS,
no explicit definitions are needed for its behavior.

Call: A call is unable to receive the media indicated in the
caller's description or wants an informal term that refers to receive data via unicast.

The protocol exchanges a dialog between
peers, generally set up for the INVITE method are shown in Fig. 1 purposes of a multimedia
conversation.

Call leg: Another name for a dialog.

Call stateful: A proxy server and in Fig. 2 is call stateful if it retains state for
a redirect server. (Note that the
messages shown in dialog from the figures have been abbreviated slightly.) In
Fig. 1, initiating INVITE to the terminating BYE
request. A call stateful proxy server accepts the INVITE request (step 1),
contacts is always stateful, but the location service with all
converse is not true.

Client: A client is any network element that sends SIP requests,
and receives SIP responses. Clients may or parts of the address (step
2) may not interact
directly with a human user. User agent clients and obtains proxies
are clients.

Conference: A multimedia session (see below) that contains
multiple participants.

Dialog: A dialog is a more precise location (step 3). The proxy server
then issues peer-to-peer SIP relationship between a

Various Authors [Page 13]

Internet Draft SIP INVITE request October 26, 2001

UAC and UAS that persists for some time. A dialog is
established by SIP messages, such as a 2xx response to the address(es) returned an
INVITE request. A dialog is identified by the
location service (step 4). The user agent server alerts the user
(step 5) a call
identifier, local address, and returns remote address. A dialog was
formerly known as 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 call leg in RFC 2543.

Downstream: A direction of this message is confirmed by the
caller using an ACK request, forwarding within a
transaction which is forwarded refers to the callee (steps
8 and 9). Note direction that an ACK can also be sent directly to the callee,
bypassing requests
flow from the proxy. user agent client to user agent server.

Final response: A response that terminates a SIP transaction, as
opposed to a provisional response that does not. All requests 2xx,
3xx, 4xx, 5xx and 6xx responses have the same Call-
ID. are final.

Informational Response: Same as a provisional response.

Initiator, calling party, caller: The redirect server shown in Fig. 2 accepts the party initiating a session
with an INVITE request (step
1), contacts request. A caller retains this role from the location service as before (steps 2 and 3) and,
instead of contacting
time it sends the newly found address itself, returns INVITE until the
address to termination of any
dialogs established by the caller (step 4), which is then acknowledged via INVITE.

Invitation: An INVITE request.

Invitee, invited user, called party, callee: The party that
receives an ACK INVITE request (step 5). The caller issues for the purposes of establishing
a new request, with session. A callee retains this role from the same
call-ID but a higher CSeq, to time it
receives the address returned INVITE until the termination of the dialog
established by that INVITE.

Isomorphic request or response: Two requests are defined to be
isomorphic for the first
server (step 6). In purposes of this document if they have
the example, same values for the call succeeds (step 7). The
caller Call-ID, To, From, CSeq, Request-
URI and callee complete the handshake with an ACK (step 8).

The next section discusses what happens top-most Via header. Two responses are
isomorphic if they have the location service
returns more than one possible alternative.

1.4.5 Locating a User

Handley/Schulzrinne/Schooler/Rosenberg [Page 14]

Internet Draft SIP July 20, 2001

====> SIP request
....> SIP response

^
| non-SIP protocols
|

Figure 1: Example of SIP proxy server

A callee may move between a number of different end systems over
time. These locations can be dynamically registered with same values for the SIP
server (Sections 1.4.7, 7). Call-ID,
To, From, CSeq and top Via header. A location server MAY message which is
isomorphic to another is also use one or
more other protocols, such known as finger (RFC 1288 [15]), rwhois (RFC
2167 [16]), LDAP (RFC 1777 [17]), multicast-based protocols [18] or
operating-system dependent mechanisms to actively determine the end
system where a user might be reachable. retransmission.

Location server: See location service.

Location service: A location server MAY return
several locations because the user service is logged in at several hosts
simultaneously or because the location server has (temporarily)
inaccurate information. The used by a SIP redirect
or proxy server combines the results to yield obtain information about a list of callee's
possible location(s). It is an abstract database, sometimes
referred to as a zero or more locations.

Handley/Schulzrinne/Schooler/Rosenberg [Page 15]

Internet Draft SIP July 20, 2001

+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( lab ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+

====> SIP request
....> SIP response

^
| non-SIP protocols
|

Figure 2: Example server. The contents of SIP redirect server

Handley/Schulzrinne/Schooler/Rosenberg the
database can be populated in many ways, including being
written by registrars.

Loop: A request that arrives at a proxy, is forwarded, and later
arrives back at the same proxy. When it arrives the second

Various Authors [Page 16] 14]

Internet Draft SIP July 20, October 26, 2001

The action taken on receiving a list of locations varies with the
type of SIP server. A SIP redirect server returns the list

time, its Request-URI is identical to the
client as Contact first time, and
other headers (Section 10.14). A SIP that affect proxy server can
sequentially or in parallel try the addresses until operation are unchanged, so
that the call is
successful (2xx response) or proxy would make the callee has declined same processing decision on
the call (6xx
response). With sequential attempts, a proxy server can implement an
"anycast" service.

If a proxy server forwards a SIP request, request it MUST add itself to made the
beginning of first time around. Looped requests
are errors, and the list of forwarders noted in procedures for detecting them and
handling them are described by the Via (Section 10.46)
headers. protocol.

Method: The Via trace ensures that replies can take the same path
back, ensuring correct operation through compliant firewalls and
avoiding request loops. On method is the response path, each host MUST remove
its Via, so primary function that routing internal information a request is hidden from
meant to invoke on a server. The method is carried in the
callee
request message itself. Example methods are INVITE and outside networks. BYE.

Outbound proxy: A SIP invitation may traverse more than one SIP proxy server. If one
of that receives all requests from a
client, even though it is not the server resolved by the
Request-URI. The outbound proxy sends these "forks" requests, after
any local processing, to the request, i.e., issues more than one request address indicated in
response to receiving the invitation request, it is possible that
Request-URI, or to another outbound proxy.

Parallel search: In a
client is reached, independently, by more parallel search, a proxy issues several
requests to possible user locations upon receiving an
incoming request. Rather than issuing one copy of request and then
waiting for the
invitation request. Each of these copies bears final response before issuing the same Call-ID, but next
request as in a different topmost Via header branch parameter (see Section 10.46).
The user agent MAY choose which final response to return for each
such request, typically returning sequential search , a 200 (OK) parallel search
issues requests without waiting for only one of them.

1.4.6 Changing an Existing Session

In some circumstances, it is desirable to change the parameters result of an
existing session. This is done previous
requests.

Provisional response: A response used by re-issuing the INVITE within the
same call leg, server to indicate
progress, but within that does not terminate a new or different body or header fields to
convey the new information. This re INVITE MUST have SIP transaction.
1xx responses are provisional, other responses are
considered final.

Proxy, proxy server: An intermediary entity that acts as both a
server and a higher CSeq
than any previous request from the client to for the server.

For example, two parties may have been conversing and then want purpose of making requests on
behalf of other clients. A proxy server primarily plays to
add
role of routing, which means its job is to ensure that a third party, switching
request is passed on to multicast another entity that can further
process the request. Proxies are also useful for efficiency. One enforcing
policy and for firewall traversal. A proxy interprets, and,
if necessary, rewrites parts of the
participants invites the third party with the new multicast address a request message before
forwarding it.

Registrar: A registrar is a server that accepts REGISTER
requests, and simultaneously sends an INVITE to places the second party, with information it receives in those
requests into the new
multicast session description, but with location service for the old call identifier.

1.4.7 Registration Services

The REGISTER request allows a client to let a proxy or redirect
server know at which address(es) domain it can be reached.
handles.

Regular Transaction: A client MAY also
use it to install call handling features at the server.

1.5 Protocol Properties

1.5.1 Minimal State

Handley/Schulzrinne/Schooler/Rosenberg regular transaction is any transaction
with a method other than INVITE, ACK, or CANCEL.

Various Authors [Page 17] 15]

Internet Draft SIP July 20, October 26, 2001

A single conference session or call involves one or more SIP
request-response transactions. Proxy servers do not have to keep
state for

Ringback: Ringback is the signaling tone produced by the calling
party's application indicating that a particular call, however, they MAY maintain state for called party is being
alerted (ringing).

Server: A server is a
single SIP transaction, as discussed network element that receives requests in Section 17. For efficiency, a
server MAY cache the results of location
order to service them, and sends back responses to those
requests.

1.5.2 Lower-Layer-Protocol Neutral

SIP makes minimal assumptions about the underlying transport Examples of servers are proxies, user agent
servers, redirect servers, and
network-layer protocols. The lower-layer can provide either registrars.

Sequential search: In a packet
or sequential search, a byte stream service, with reliable or unreliable service.

In an Internet context, SIP is able proxy server
attempts each contact address in sequence, proceeding to utilize both UDP and TCP as
transport protocols, among others. UDP allows
the application to more
carefully control next one only after the previous has generated a non-
2xx final response.

Session: From the timing SDP specification: "A multimedia session is a
set of messages multimedia senders and their retransmission, to
perform parallel searches without requiring TCP connection state for
each outstanding request, receivers and the data
streams flowing from senders to use multicast. Routers can more
readily snoop SIP UDP packets. TCP allows easier passage through
existing firewalls.

When TCP is used, SIP receivers. A multimedia
conference is an example of a multimedia session." (RFC
2327 [6]) (A session as defined for SDP can use comprise one or
more connections to attempt to
contact RTP sessions.) As defined, a user or callee can be invited
several times, by different calls, to modify parameters of an existing conference.
Different SIP requests for the same SIP call MAY use different TCP
connections or session. If
SDP is used, 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 session is defined by the scope concatenation of this document. All entities MUST
support UDP. User agents SHOULD implement TCP transport. Stateful
proxy, registrar,
the user name , session id , network type , address type
and redirect servers MUST implement TCP transport.
Other transports MAY be supported by any entity.

1.5.3 Text-Based

SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This
allows easy implementation address elements in languages such as Java, Tcl and Perl,
allows easy debugging, and most importantly, makes the origin field.

(SIP) transaction: A SIP flexible transaction occurs between a client 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.

2 SIP Uniform Resource Locators

SIP URLs are used within SIP server and comprises all messages from the first request
sent from the client to indicate the originator
(From), current destination (Request-URI) and final recipient (To) of server up to a SIP request, and final (non-1xx)
response sent from the server to specify redirection addresses (Contact). the client, and the ACK
for the response in the case the response was a 2xx. The
ACK for a 2xx response is a separate transaction.

Spiral: A spiral is a SIP
URL can also be embedded in web pages or other hyperlinks request which is routed to indicate

Handley/Schulzrinne/Schooler/Rosenberg [Page 18]

Internet Draft SIP July 20, 2001 a proxy,
forwarded onwards, and arrives once again at that proxy,
but this time, differs in a particular user or service can be called via SIP. When used as way which will result in a hyperlink, the SIP URL indicates
different processing decision than the use of original request.
Typically, this means that it has a Request-URI that
differs from the INVITE method.

The SIP URL scheme previous arrival. A spiral is not an error
condition, unlike a loop.

Stateless proxy: A logical entity that does not maintain the
client or server transaction state machines defined to allow setting SIP request-header
fields in this
specification when it processes requests. A stateless proxy
forwards every request it receives downstream and every
response it receives upstream.

Stateful proxy: A logical entity that maintains the client and
server transaction state machines defined by this

Various Authors [Page 16]

Internet Draft SIP message-body.

This corresponds to the use of mailto: URLs. It makes it
possible, for example, to specify October 26, 2001

specification during the subject, urgency or
media types processing of calls initiated through a web page or request. Also
known as
part a transaction stateful proxy. The behavior of an email message. a
stateful proxy is further defined in Section 16. A SIP URL follows stateful
proxy is not the guidelines same as a call stateful proxy.

Transaction User (TU): The layer of RFC 2396 [10] and has protocol processing that
resides above the syntax
shown in Fig. 3. The syntax is described using Augmented Backus-Naur
Form (see Section C). Although transaction layer. Transaction users
include the ABNF described in Section C uses
implicit whitespace, unescaped whitespace MUST NOT be present UAC core, UAS core, and proxy core.

Upstream: A direction of message forwarding within a SIP URL. Any reserved characters have transaction
which refers to be escaped and the direction that responses flow from the
"set of characters reserved within any given URI component
user agent server to user agent client.

URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [10].

User agent client (UAC): A user agent client is defined
by a logical entity
that component. In general, creates a character is reserved if new request, and then uses the
semantics client
transaction state machinery to send it. The role of UAC
lasts only for the URI changes duration of that transaction. In other
words, if the character is replaced with its
escaped US-ASCII encoding" [10]. Excluded US-ASCII characters [10],
such as space and control characters and characters used a piece of software initiates a request, it acts
as URL
delimiters, also MUST be escaped. URLs MUST NOT contain unescaped
space and control characters.

The URI character classes referenced above are described in Appendix
C.

The components a UAC for the duration of that transaction. If it
receives a request later on, it takes on the SIP URI have role of a User
Agent Server for the following meanings.

user: processing of that transaction.

UAC Core: The name set of processing functions required of a UAC that
reside above the transaction and transport layers.

User agent server (UAS): A user addressed. Note agent server is a logical entity
that this field MAY
be empty where the destination host does not have generates a notion
of users, e.g., response to a SIP request. The response
accepts, rejects or redirects the request. This role lasts
only for embedded devices.

telephone-subscriber: If the host is an Internet telephony
gateway, duration of that transaction. In other words,
if a telephone-subscriber field MAY be used instead piece of software responds to a user field. The telephone-subscriber field uses request, it acts as a
UAS for the
notation duration of RFC 2806 [19]. Any characters that transaction. If it generates a
request later on, it takes on the role of a User agent
client for the un-escaped
"telephone-subscriber" processing of that are not either in the set
"unreserved" or "user-unreserved" MUST be escaped. transaction.

UAS Core: The set of characters not reserved in processing functions required at a UAS that
reside above the RFC 2806 description transaction and transport layers.

User agent (UA): A logical entity which can act as both a user
agent client and user agent server for the duration of
telephone-subscriber contains a number
dialog.

The role of characters in
various syntax elements that need to be escaped when used
in SIP URLs, for example quotation marks (%22), hash (%23),
colon (%3a), at-sign (%40) UAC and UAS as well as proxy and redirect servers are
defined on a transaction-by-transaction basis. For example, the "unwise" characters,
i.e., punctuation of %5b user
agent initiating a call acts as a UAC when sending the initial INVITE
request and above.

Handley/Schulzrinne/Schooler/Rosenberg as a UAS when receiving a BYE request from the callee.

Various Authors [Page 19] 17]

Internet Draft SIP July 20, October 26, 2001

SIP-URL = "sip:" [ userinfo "@" ] hostport
url-parameters [ headers ]
userinfo = [ user | telephone-subscriber [ ":" password ]]
user = *( unreserved | escaped | user-unreserved)
user-unreserved = "&" | "=" | "+" | "$" | "," | ";" | "?" | "/"
password = *( unreserved | escaped
| "&" | "=" | "+" | "$" | "," )
hostport = host [ ":" port ]
host = hostname | IPv4address | IPv6reference
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEX
port = *digit
url-parameters = *( ";" url-parameter )
url-parameter = transport-param | user-param | method-param
| ttl-param | maddr-param | other-param
transport-param = "transport=" ( "udp" | "tcp" | "sctp" | "tls"
| other-transport)
other-transport = token
user-param = "user=" ( "phone" | "ip" | other-user)
other-user = token
method-param = "method=" Method
ttl-param = "ttl=" ttl
maddr-param = "maddr=" host
other-param = pname ["=" pvalue]
pname = 1*paramchar
pvalue = 1*paramchar
paramchar = param-unreserved | unreserved | escaped
param-unreserved= "[" | "]" | "/" | ":" | "&" | "+" | "$"
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*( hnv-unreserved | unreserved | escaped )
hvalue = *( hnv-unreserved | unreserved | escaped )
hnv-unreserved = "[" | "]" | "/" | "?" | ":" | "+" | "$"

Figure 3:

Similarly, the same software can act as a proxy server for one
request and as a redirect server for the next request.

Proxy, location and registrar servers defined above are logical
entities; implementations MAY combine them into a single application
program.

7 SIP URL syntax

Handley/Schulzrinne/Schooler/Rosenberg [Page 20]

Internet Draft Messages

SIP July 20, 2001

The telephone number is a special case of a user name text-based protocol and
cannot be distinguished by uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 [11]).

A SIP message is either a BNF. Thus, request from a URL parameter,
user, is added client to distinguish telephone numbers a server, or a
response from user
names.

The user parameter value "phone" indicates that a server to a client.

Both Request (section 7.1) and Response (section 7.2) messages use
the user
part contains generic-message format of RFC 822 [12]. Both types of messages
consist of a telephone number. Even without this
parameter, recipients start-line, one or more header fields (also known as
"headers"), an empty line indicating the end of SIP URLs MAY interpret the pre-@
part as header fields,
and an optional message-body.

generic-message = start-line
*message-header
CRLF
[ message-body ]

The start-line, each message-header line, and the empty line MUST be
terminated by a telephone number carriage-return line-feed sequence (CRLF). Note that
the empty line MUST be present even if local restrictions on the
name space message-body is not.

Except for user name allow it.

password: The SIP scheme MAY use the format "user:password" above difference in character sets, much of SIP's
message and header field syntax is identical to HTTP/1.1. Rather than
repeating the userinfo field. The syntax and semantics here we use [HX.Y] to refer to
Section X.Y of passwords in the userinfo is
NOT RECOMMENDED, because the passing of authentication
information in clear text (such as URIs) has proven to be a
security risk in almost every case where it has been used.

host: The host part SHOULD be a fully-qualified domain name or
numeric IP address.

The mailto: URL and RFC 822 email addresses require current HTTP/1.1 specification (RFC 2616 [8]).

Note, however, that
numeric host addresses ("host numbers") are enclosed in
square brackets (presumably, since host names might be
numeric), while host numbers without brackets are used for
all other URLs. The SIP URL requires the latter form,
without brackets.

port: The port number to send a request to. If is not present, the
procedures outlined in Section 1.4.2 an extension of HTTP.

7.1 Requests

SIP Requests are used to determine
the port number to send distinguished by having a request to.

URL parameters: SIP URLs can define specific parameters of Request-Line for a start-
line. A Request-Line begins with a method token, followed by the
request. URL parameters are added after
Request-URI and the host component protocol version, and ending with CRLF. The
elements are separated by semi-colons. The transport parameter
determines the the transport mechanism to be used for
sending SIP requests and responses. SIP can use any network
transport protocol; parameter names SP characters. No CR or LF are defined for UDP
[20], TCP [21], TLS [22], and SCTP. UDP is to be assumed
when no explicit transport parameter is included. The maddr
parameter indicates the server address to be contacted for
this user, overriding the address supplied allowed
except in the host
field. This address is typically, but not necessarily, a
multicast address.

The maddr field can be used to force requests from
traveling users to visit a home proxy even if an
outbound proxy end-of-line CRLF sequence. No LWS is used.

Handley/Schulzrinne/Schooler/Rosenberg allowed in any of
the elements.

Various Authors [Page 21] 18]

Internet Draft SIP July 20, October 26, 2001

The ttl parameter determines the time-to-live value of the
UDP multicast packet

Method Request-URI SIP-Version

o Method

This specification defines six methods : REGISTER for
registering contact information, INVITE, ACK and MUST only be used if maddr is a
multicast address CANCEL for
setting up sessions, BYE for terminating sessions and the transport protocol is UDP. OPTIONS
for querying servers about their capabilities. SIP extensions
may define additional methods.

o Request-URI

The
user parameter was Request-URI is a SIP URL as described above. For example, to specify
to call j.doe@big.com using multicast to 239.255.255.1 with in Section 21.1 or a ttl of 15,
general URI (RFC 2396 [9]). It indicates the following URL would be used:

sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 user or service
to which this request is being addressed. The transport, maddr, Request-URI
MUST NOT contain unescaped spaces or control characters and ttl parameters
MUST NOT be used enclosed in the From and To header fields; they are ignored if
present.

For Request-URIs, these parameters are useful
primarily for outbound proxies.

Receivers MUST silently ignore any URI parameters that they
do not understand.

Headers: Headers of the "<>".

SIP request can be defined servers MAY support Request-URIs with schemes other than
"sip", for example the "?" "tel" URI scheme of RFC 2806 [13]. It
MAY translate non-SIP URIs using any mechanism within at its
disposal, resulting in either a SIP URL. The special hname "body"
indicates that the associated hvalue is URI or some other scheme.

o SIP Version

Both request and response messages include the message-body version of
the SIP INVITE request. Headers MUST NOT be used
in the
From use, and To header fields follow [H3.1] (with HTTP replaced by SIP, and the Request-URI; they are
ignored if present. hname
HTTP/1.1 replaced by SIP/2.0) regarding version ordering,
compliance requirements, and hvalue are encodings upgrading of a version numbers. To
be compliant with this specification, applications sending SIP header name and value, respectively. All URL reserved
characters in the header names and values
messages MUST be escaped.

Method: The method include a SIP- Version of the SIP request can be specified with the
method parameter. This parameter "SIP/2.0". The string
is case-insensitive, but implementations MUST NOT be used in the
From and To header fields and send upper-case.

Unlike HTTP/1.1, SIP treats the Request-URI; they version number as a
literal string. In practice, this should make no
difference.

7.2 Responses

SIP Responses are
ignored if present.

Table 2 summarizes where the components distinguished by having a Status-Line for a start-
line. A Status-Line, consists of the SIP URL can be used.
Entries marked "m" are mandatory, those marked "o" are optional, protocol version followed by a
numeric Status-Code and
those marked "-" are not allowed. For optional elements, the second
column indicates the default value if the its associated textual phrase, with each
element separated by SP characters. No CR or LF is not present.

Examples of SIP URLs are:

sip:j.doe@big.com
sip:j.doe:secret@big.com;transport=tcp
sip:j.doe@big.com?subject=project%20x&priority=urgent

Handley/Schulzrinne/Schooler/Rosenberg allowed except in
the final CRLF sequence.

SIP-version Status-Code Reason-Phrase

Various Authors [Page 22] 19]

Internet Draft SIP July 20, October 26, 2001

default Req.-URI To From Contact Rec.-Route external
user -- o o o o o o
password -- o o - o o o
host mandatory m m m m m m
port 5060 o o o o o o
user-param ip o o o o o o
method INVITE - - - o - o
maddr-param -- o - - o m o
ttl-param 1 o - - o - o
transp.-param udp o - - o - o
other-param -- o o o o o o
headers -- - - - o - o

Table 2: Use and default values of URL components for SIP headers,
Request-URI and references

sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com
sip:alice@10.1.2.3
sip:alice@example.com
sip:alice%40example.com@gateway.com
sip:alice@registrar.com;method=REGISTER

2.1 SIP URL Comparison

SIP URLs are compared for equality according to

The Status-Code is a 3-digit integer result code that indicates the following rules:

o Comparisons
outcome of scheme name ("sip"), domain names, parameter
names an attempt to understand and header names are case-insensitive, all other
comparisons are case-sensitive.

o satisfy a request. The ordering
Reason-Phrase is intended to give a short textual description of parameters and headers the
Status-Code. The Status-Code is intended for use by automata, whereas
the Reason-Phrase is intended for the human user. A client is not significant in
comparing SIP URLs.

o user
required to examine or telephone-subscriber, password, host, port and any
url-parameter parameters of display the URI must match. If one Reason-Phrase.

The first digit of the
components in Status-Code defines the previous sentence is omitted, it matches
based on its default value. (For example, otherwise equivalent
URLs without class of response.
The last two digits do not have any categorization role. For this
reason, any response with a port specification status code between 100 and 199 is
referred to as a "1xx response", any response with port 5060 match.)
URL parameters (which excludes telephone-subscriber, password, a status code
between 200 and port) not found in both URLs being compared, for which
there is no default value, are ignored, 299 as a "2xx response", and therefore not
included in the comparison operation. Other URL components not
found in both URLs being compared, so on. SIP/2.0 allows 6
values for which there is no

Handley/Schulzrinne/Schooler/Rosenberg [Page 23]

Internet Draft SIP July 20, 2001

default value, are included in the comparison operation, and first digit:

1xx: Informational -- request received, continuing to process
the result will be that request;

2xx: Success -- the URLs do not match.

o Characters other than those action was successfully received,
understood, and accepted;

3xx: Redirection -- further action needs to be taken in order to
complete the "reserved" and "unsafe"
sets (see RFC 2396 [10]) are equivalent request;

4xx: Client Error -- the request contains bad syntax or cannot
be fulfilled at this server;

5xx: Server Error -- the server failed to their ""%" HEX HEX"
encoding.

o An IP address that is fulfill an apparently
valid request;

6xx: Global Failure -- the result of a DNS lookup request cannot be fulfilled at any
server.

Full definitions of a host
name does not match that host name.

o URL parameters that have no default value are compared only if
they are present these classes and each registered code appear in both URLs.

Thus, the following URLs are equivalent:

sip:juser@%65xample.com:5060
sip:juser@ExAmPlE.CoM;Transport=udp

while

SIP:JUSER@ExAmPlE.CoM;Transport=udp
sip:juser@ExAmPlE.CoM;Transport=UDP

are not.

The following URLs are also equivalent:

sip:user@domain.com;foo=baz
sip:user@domain.com

while

sip:user@domain.com
sip:domain.com

are not.
Section 23.

7.3 Header Fields

SIP header fields such as Contact, From and To are equal if similar to HTTP header fields in both syntax
and only if
their URIs match under semantics. In particular, SIP header fields follow the [H4.2]
definitions of syntax for message-header, the rules above for extending
header fields over multiple lines, the use of multiple message-header
fields with the same field-name, and if their the rules regarding ordering of
header parameters
(such fields.

7.3.1 Header Field Format

Header fields follow the same generic header format as contact-param, from-param and to-param) match that given in name and
parameter value, where parameter names and token parameter values are
compared ignoring case and quoted-string parameter values are case-
sensitive.

Handley/Schulzrinne/Schooler/Rosenberg
Section 3.1 of RFC 822 [12]. Each header field consists of a field

Various Authors [Page 24] 20]

Internet Draft SIP July 20, October 26, 2001

2.2 Non-SIP URLs

SIP header fields

name followed by a colon (":") and the Request-URI MAY contain non-SIP URLs, with field value.
field-name: field-value

Note that the exceptions noted below. As an example, if a call from formal grammar for a telephone
is relayed to message-header specified in
Section 26 allow for an arbitrary amount of whitespace on either side
of the Internet via SIP, colon. No space before the SIP From header field might
contain colon and a tel: URL [19].

In single space (SP)
between the following locations, only SIP URLs are allowed:

o Request-URI in a REGISTER request;

o Contact header field in INVITE and colon and 2xx responses to
INVITE.

Implementations MAY compare non-SIP URLs by treating them as generic
URIs [10] or, alternatively, compare them byte-by-byte.

3 SIP Message Overview

SIP the field-value is a text-based protocol preferred. That is,

Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch

are all valid, and uses the ISO 10646 character set in
UTF-8 encoding (RFC 2279 [23]). Senders MUST terminate lines with a
CRLF, equivalent, but receivers MUST also interpret CR and LF by themselves as
line terminators. Only the combinations CR CR, LF LF and CRLF CRLF
terminate last is the message header. Implementations MUST only send CRLF
CRLF.

CR preferred form.

Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or horizontal tab (HT). The line
break and LF instead the whitespace at the beginning of CRLF is for backwards-compatibility;
their use is deprecated.

Except for the above difference in character sets and next line
termination, much of are
treated as a single SP character. Thus the message syntax is and header fields following are
identical to HTTP/1.1; rather than repeating equivalent:

Subject: I know you're there, pick up the syntax phone and semantics
here we use [HX.Y] talk to refer me!
Subject: I know you're there,
pick up the phone
and talk to Section X.Y me!

The relative order of header fields with different field names is not
significant. The relative order of those with the current HTTP/1.1
specification (RFC 2616 [9]). In addition, we describe SIP same field name is
important. Multiple header fields with the same field-name may be
present in both
prose a message if and an augmented Backus-Naur form (ABNF). See section C only if the entire field-value for an
overview of ABNF.

Note, however, that SIP
header field is not an extension of HTTP.

Unlike HTTP, SIP MAY use UDP or other unreliable datagram protocols.
Each such datagram carries one request or response. Datagrams,
including all headers, SHOULD NOT defined as a comma-separated list (i.e., #(values)).
It MUST be larger than possible to combine the path maximum
transmission unit (MTU) if multiple header fields into one
"field-name: field-value" pair, without changing the MTU is known, or 1500 bytes if semantics of the MTU
is unknown. However, implementations
message, by appending each subsequent field-value to the first, each
separated by a comma.

Implementations MUST be able to handle messages
up to process multiple header fields with
the maximum datagram packet size. For UDP, this size is 65,535
bytes, including headers.

Handley/Schulzrinne/Schooler/Rosenberg same name in any combination of the single-value-per-line or
comma-separated value forms.

The following blocks of headers are valid and equivalent:

Route: sip:alice@atlanta.com
Subject: Lunch
Route: sip:bob@biloxi.com
Route: sip:carol@chicago.com

Various Authors [Page 25] 21]

Internet Draft SIP July 20, October 26, 2001

The MTU

Route: sip:alice@atlanta.com, sip:bob@biloxi.com
Route: sip:carol@chicago.com
Subject: Lunch

Subject: Lunch
Route: sip:alice@atlanta.com, sip:bob@biloxi.com, sip:carol@chicago.com

Each of 1500 bytes accommodates encapsulation within the
"typical" ethernet MTU without IP fragmentation. Recent
studies [24] indicate that an MTU of 1500 bytes following blocks is a
reasonable assumption. The next lower common MTU values are
1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
[25]). Thus, another reasonable value would be a message
size of 950 bytes, valid but not equivalent to accommodate packet headers within the
SLIP MTU without fragmentation.

A SIP message
others:

Route: sip:alice@atlanta.com
Route: sip:bob@biloxi.com
Route: sip:carol@chicago.com

Route: sip:bob@biloxi.com
Route: sip:alice@atlanta.com
Route: sip:carol@chicago.com

Route: sip:alice@atlanta.com,sip:carol@chicago.com,sip:bob@biloxi.com

The format of a header field-value is defined per header-name. It
will always be either a request from a client to a server, an opaque sequence of TEXT-UTF8 octets, or a
response from a server to a client.

SIP-message = Request | Response

Both Request (section 4) and Response (section 9) messages use the
generic-message format
combination of RFC 822 [26] for transferring entities (the
body whitespace, tokens, separators, and quoted strings.
Many of them will adhere to the message). Both types of messages consist general form of a start-line,
one or more header fields (also known as "headers"), an empty line
(i.e., value followed by a line with nothing preceding the carriage-return line-feed
(CRLF)) indicating the end
semi-colon separated sequence of parameter-name, parameter-value
pairs:
field-name: field-value *(;parameter-name=parameter-value)

When comparing headers, field names are always case-insensitive.
Unless otherwise stated in the definition of a particular header fields,
field, field values, parameter names, and an optional
message-body. To avoid confusion with similar-named headers parameter values (tokens in HTTP,
we refer to the headers describing the message body
general) are case-insensitive. Unless specified otherwise, values
expressed as entity
headers. These components quoted strings are described in detail in the upcoming
sections.

generic-message = start-line
*message-header
CRLF
[ message-body ]

start-line = Request-Line | ;Section 4.1
Status-Line ;Section 9.1

message-header = ( general-header
| request-header
| response-header
| entity-header )

Handley/Schulzrinne/Schooler/Rosenberg case-sensitive.

The following are equivalent:

Contact: <sip:alice@atlanta.com>;expires=3600
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600

Contact-Disposition: session;handling=optional
contact-disposition: Session;HANDLING=OPTIONAL

Various Authors [Page 26] 22]

Internet Draft SIP July 20, October 26, 2001

In the interest of robustness, any leading empty line(s) MUST be
ignored. In other words, if the Request

The following are not equivalent;

Warning: 370 devnull "Choose a bigger pipe"
Warning: 370 devnull "CHOOSE A BIGGER PIPE"

7.3.2 Header Field Classification

Some header fields only make sense in requests or responses. These
are called Request Header Fields and Response message begins
with one or more CRLF, CR, Header fields
respectively. Those header fields that can appear in either a
request or LFs, these characters response are called General Header Fields. If a header
appears in a message not matching its category (such as a request
header in a response), it MUST be ignored.

4 Request

The Request message format is shown below:

Request = Request-Line ; Section 4.1
*( general-header
| request-header
| entity-header )
CRLF
[ message-body ] ; Section 12

4.1 Request-Line

The Request-Line begins with 22 defines the
classification of each header.

7.3.3 Compact Form

SIP provides a method token, followed by mechanism to represent common header fields in an
abbreviated form. This may be useful when messages would otherwise
become to large to be carried on the
Request-URI and transport available to it
(exceeding the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF MTU when using UDP for example). These compact forms
are allowed
except defined in Section 22. A compact form MAY be substituted for the final CRLF sequence. No LWS is allowed in
longer form of a header name at any time without changing the
semantics of a the
elements. The Request-URI MUST NOT be enclosed in "<>". absoluteURI
is defined in [H3.2.1].

Request-Line = Method SP Request-URI SP SIP-Version CRLF
Request-URI = SIP-URL | absoluteURI
SIP-Version = "SIP/2.0"

4.2 Methods

The methods are described message. Multiple header fields in detail below: REGISTER 7 for registering
contact information, INVITE, ACK and CANCEL (Section 5.1) for setting
up sessions, BYE (Section 6) for terminating sessions and OPTIONS
(Section 8) for querying servers about their capabilities. SIP
extensions may define additional methods ("extension-method").

Proxy and redirect servers treat all methods other than INVITE a message with
the same header name MAY appear with an arbitrary mix of its long and
CANCEL, whether
short field name form. Implementations MUST accept both the method is long and
short forms of each header name.

7.4 Bodies

Requests, including new requests defined in extensions to this specification or
elsewhere, in
specification, MAY contain message bodies unless otherwise noted.

For response messages, the same way. Thus, no method-specific support is
required in these servers for methods other than INVITE request method and CANCEL.
Methods that are not supported by a user agent server or registrar
cause a 501 (Not Implemented) the response to be returned (Section 11).

Handley/Schulzrinne/Schooler/Rosenberg [Page 27] status
code determine the type and interpretation of any message body. All
responses MAY include a body.

7.4.1 Message Body Type

The Internet Draft SIP July 20, 2001

Table 3: SIP headers

Handley/Schulzrinne/Schooler/Rosenberg header-field value.

Various Authors [Page 28] 23]

Internet Draft SIP July 20, October 26, 2001

4.3 Request-URI

The Request-URI is a SIP URL as described "multipart" MIME type defined in Section 2 or a general
URI (RFC 2396 [10]). In particular, it MUST NOT contain unescaped
spaces or control characters. It indicates the user or service to
which this request is being addressed. Unlike the To field, the
Request-URI RFC 2046 [14] MAY be re-written by proxies.

As shown in Table 2, used within
the Request-URI MAY contain body of the user-param
parameter as well as transport-related parameters. A server message.

Implementations that
receives a SIP-URL with illegal elements removes them before further
processing.

Transport-related parameters are needed when a UAC proxies
all send requests containing multipart message
bodies MUST be able to send a default proxy, which would then need this
information to generate the appropriate request.

Typically, the UAC sets the Request-URI and To to the same
SIP URL, presumed to remain unchanged over long time
periods. However, session description as a non-multipart
message body if the UAC has cached a more direct path
to remote implementation requests this through an
Accept header field.

7.4.2 Message Body Length

The body length in bytes is provided by the callee, e.g., from Content-Length header
field. Section 22.14 describes the Contact necessary contents of this header field
in detail.

The "chunked" transfer encoding of a
response to a previous request, the To would still contain
the long-term, "public" address, while the Request-URI
would HTTP/1.1 MUST NOT be set to the cached address.

Proxy and redirect servers MAY use used for SIP.
(Note: The chunked encoding modifies the information body of a message in the Request-URI
and request header fields order
to handle the request and possibly rewrite
the Request-URI. For example, transfer it as a request addressed to the generic
address sip:sales@acme.com is proxied to the particular person, e.g.,
sip:bob@ny.acme.com , with the To field remaining as
sip:sales@acme.com. At ny.acme.com , Bob then designates Alice as
the temporary substitute.

The host part series of the Request-URI typically agrees chunks, each with its own size
indicator.)

7.5 Framing SIP messages

Unlike HTTP, SIP MAY use UDP or other unreliable datagram protocols.
Each such datagram carries one of the
host names of the receiving server. If it does not, the server request or response. Datagrams,
including all headers, SHOULD
proxy NOT be larger than the request to path maximum
transmission unit (MTU) if the address indicated MTU is known, or return a 404 (Not
Found) response 1500 bytes if it the MTU
is unwilling or unable unknown. However, implementations MUST be able to handle messages
up to do so. For example,
the Request-URI and server host name can disagree in the case maximum datagram packet size. For UDP, this size is 65,535
bytes, including headers.

The MTU of a
firewall proxy 1500 bytes accommodates encapsulation within the
"typical" ethernet MTU without IP fragmentation. Recent
studies [15] indicate that handles outgoing calls. This mode an MTU of operation 1500 bytes is
similar a
reasonable assumption. The next lower common MTU values are
1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
[16]). Thus, another reasonable value would be a message
size of 950 bytes, to that accommodate packet headers within the
SLIP MTU without fragmentation.

In the interest of HTTP proxies.

Handley/Schulzrinne/Schooler/Rosenberg robustness, any leading empty line(s) MUST be
ignored. In other words, if the Request or Response message begins
with one or more CRLF, CR, or LFs, these characters MUST be ignored.

Likewise, Implementations processing SIP messages over stream
oriented transports MUST ignore noise between messages.

8 General User Agent Behavior

Various Authors [Page 29] 24]

Internet Draft SIP July 20, October 26, 2001

SIP servers MAY support Request-URIs with schemes other than "sip",
for example the "tel" URI scheme [19].

A user agent represents an end system. It MAY translate non-SIP URIs
using any mechanism at its disposal, resulting in either contains a SIP URI or
some other scheme.

If User Agent
Client (UAC), which generates requests, and a SIP server receives User Agent Server (UAS)
which responds to them. A UAC is capable of generating a request with
based on some external stimulus (the user clicking a URI indicating button, or a scheme the
server does not understand, the server MUST return
signal on a PSTN line), and processing a 400 (Bad
Request) response. It MUST do this even if A UAS is capable
of receiving a request, and generating response, based on user input,
external stimulus, the To header field
contains result of a scheme program execution, or some other
mechanism.

When a UAC sends a request, it does understand, since proxies are responsible
for processing the Request-URI. (The To field is only will pass through some number of interest to proxy
servers, which forward the UAS.)

4.3.1 SIP Version

Both request towards the UAS. When the UAS
generates a response, the response is forwarded towards the UAC.

UAC and UAS procedures depend strongly on two factors. First, whether
the request or response messages include is inside or outside of a dialog, and second,
based on the version method of SIP a request. Dialogs are discussed thoroughly in use,
Section 12; they represent a peer-to-peer relationship between user
agents, and follow [H3.1] (with HTTP replaced are established by SIP, specific SIP methods, such as INVITE.

In this section, we discuss the method independent rules for UAC and HTTP/1.1 replaced
by SIP/2.0) regarding version ordering, compliance requirements, and
upgrading
UAS behavior when processing of requests that are outside of version numbers. To be compliant with this
specification, applications sending SIP messages MUST include a SIP-
Version
dialog. This includes, of "SIP/2.0". The string is case-insensitive, but
implementations MUST use upper-case.

Unlike HTTP/1.1, SIP treats course, the version number as requests which themselves
establish a literal
string. In practice, this should make no difference.

4.4 Option Tags

Option tags dialog.

8.1 UAC Behavior

8.1.1 Generating the Request

A valid SIP request formulated by a UAC MUST at a minimum contain the
following headers: To, From, CSeq, Call-ID, and Via; all of these
headers are unique identifiers used to designate new options mandatory in
SIP. all SIP messages. These tags five headers are used in Require (Section 10.35), Supported
(Section 10.41) and Unsupported (Section 10.44) header fields.

Syntax:

option-tag = token

See Section C for the definition of token. The creator
fundamental building blocks of a new SIP
option MUST either prefix message, as they jointly provide
for most of the option with their reverse domain name
or register critical message routing services including the new option with
addressing of messages, the Internet Assigned Numbers
Authority (IANA).

An example routing of responses, ordering of
messages, and the unique identification of transactions.

Examples of requests send outside of a reverse-domain-name option is "com.foo.mynewfeature",
whose inventor can be reached at "foo.com". For these features,
individual organizations are responsible dialog include an INVITE to
establish a session (Section 13) and an OPTIONS to query for ensuring
capabilities (Section 11).

8.1.1.1 To

The To general-header field first and foremost specifies the desired
"logical" recipient of the request, or the address of record of the
user or resource that option
names do is the target of this request. This may or may
not collide within be the same domain. The host name part ultimate recipient of the option MUST request. The To header MAY
contain a SIP URI, but it may also make use lower-case; of other URI schemes (for
example as the option name is case-sensitive.

Handley/Schulzrinne/Schooler/Rosenberg tel URL [13]) when appropriate. The To header field

Various Authors [Page 30] 25]

Internet Draft SIP July 20, October 26, 2001

Options registered with IANA do not

allows for a display name; this is meant to contain periods and are globally
unique. IANA option tags are case-sensitive.

4.4.1 Registering New Option Tags with IANA

When registering a new SIP option, descriptive
version of the following information MUST be
provided:

o Name URI, and description of option. The name MAY be of any length,
but SHOULD is intended to be no more than twenty characters long. The name
MUST consist of alphanum (See Figure 3) characters only;

o A listing of any new SIP header fields, header parameter
fields or parameter values defined by this option. displayed to a user
interface.

A SIP
option MUST NOT redefine UAC may learn how to populate the To header fields or parameters defined field for a particular
request in either RFC 2543, any standards-track extensions to RFC
2543, or other extensions registered through IANA.

o Indication a number of who has change control over ways. Usually the option (for
example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or user will suggest the To
header field through a particular company human interface, perhaps inputting the URI
manually or group selecting it from some sort of
companies);

o address book.

A reference to a further description, if available, for
example (in order request outside of preference) an RFC, a published paper, a
patent filing, dialog MUST NOT contain a technical report, documented source code or a
computer manual;

o Contact information (postal and email address).

Registrations should be sent to iana@iana.org

This procedure has been borrowed from RTSP [4] and the RTP
AVP [27].

5 INVITE, ACK and CANCEL

5.1 INVITE

The INVITE method indicates that tag; the user or service is being invited
to participate tag in a session. The message body MAY contain a
description the
To field of a request identifies the session to which peer of the callee dialog. Since no
dialog is being invited. established, no tag is present.

For
two-party calls, further information on the caller To header see Section 22.37.

The following is an example of valid To header:

To: Carol <sip:carol@chicago.com>

8.1.1.2 From

The From general-header field indicates the type logical identity of media it is able to
receive and possibly the media it is willing to send as well as their
parameters such as network destination. A success response MUST
indicate in its message body which media
initiator of the callee wishes to receive
and MAY indicate request, possibly the media user's address of record. Like
the callee To field, it contains a URI and optionally a display name. It is going to send.

Handley/Schulzrinne/Schooler/Rosenberg [Page 31]

Internet Draft
used by SIP July 20, 2001

Not all session description formats have the ability elements to
indicate sending media.

The caller MAY choose determine processing rules to apply to omit the request body (i.e., not send a
session description) or send a session description that does not list
any media types. This indicates
request (for example, automatic call rejection). As such, it is very
important that the caller does URI not know its
desired media characteristics until the call has been accepted. In
this case, the UAS SHOULD still return a session description in its
informational (1xx) contain IP addresses or success (2xx) response, containing those media
streams and codecs it supports.

If the INVITE request did host names, since
these are not logical names.

The From header field allows for a display name; this is meant to
contain a complete session description,
the caller MUST include one in descriptive version of the ACK request. A UAC MUST NOT send
an updated session description in an ACK request if it had already
sent URI, and is intended to be
displayed to a session description in the INVITE request. If the user interface. A UAC wishes
to modify the session after the call setup has begun, it MUST
initiate another INVITE transaction after SHOULD use the current one has
completed.

Delaying display name
"Anonymous" if the session description until identity of the ACK request client is
useful for gateways from H.323v1 to SIP, where remain hidden.

Usually the H.323
media characteristics are not known until value that populates the call is
established.

A server MAY automatically respond to an invitation for From header field in requests
generated by a conference
the particular user agent is already participating in, identified either pre-provisioned by the SIP
Call-ID user
or a globally unique identifier within by the session
description, with a 200 (OK) response.

The behavior administrators of UAS depend on whether they are Internet telephony
gateways to the PSTN. A UAS not acting as a gateway which receives an
INVITE with user's local domain. If a Request-URI particular
user agent is used by multiple users, it might have switchable
profiles that does not correspond include a URI corresponding to one the identity of its
configured addresses, MUST respond with 404 (Not Found).

A UAS acting as a gateway translates the INVITE request into a
telephony signaling message. If the INVITE has a Call-ID value that
matches a recent call, the UAS compares the Request-URI with the
Request-URI
profiled user. Recipients of requests can authenticate the previous INVITE originator
of a request for the same Call-ID. If
the Request-URI contains additional digits in the "user" part, the
UAS treats the INVITE as adding additional digits order to the original
dialed string. This is known as overlap dialing.

If the gateway knows ascertain that the telephone number is incomplete, it
returns a 484 (Address Incomplete) status response.

If a user agent receives an INVITE request they are who their From
header field claims they are (see Section 20.2 for an existing call leg
with more on
authentication).

The From field MUST contain a higher CSeq sequence number than any previous INVITE for new "tag" parameter, chosen by the

Handley/Schulzrinne/Schooler/Rosenberg UAC.
See Section 21.3 for details on choosing a tag.

Various Authors [Page 32] 26]

Internet Draft SIP July 20, October 26, 2001

same Call-ID, it MUST check any version identifiers in the session
description or, if there are no version identifiers, the content of

For further information on the session description to From header see if it has changed. Section 22.20.

Examples:

From: "Bob" <sip:bob@biloxi.com> ;tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

8.1.1.3 Call-ID

The Call-ID general-header field acts as a unique identifier to group
together series of messages. It MUST also
inspect any other header fields for changes. If there is always the same for all requests
and responses sent by either UA in a change, dialog. It is also the user agent MUST update same in
each registration from a UA within a single boot cycle.

In a new request created by a UAC outside of any internal state or information
generated dialog, unless
overridden by method specific behavior, it MUST be selected by the
UAC as a result of a globally unique identifier over space and time; all SIP
user agents must have a means to guarantee that header. If the session description has
changed, the Call-ID headers
they produce will not be inadvertently generated by any other user agent server MUST adjust the session parameters
accordingly, possibly after asking
agent.

Use of cryptographically random identifiers [17] in the user for confirmation.
(Versioning generation of
Call-IDs is RECOMMENDED. Implementations MAY use the form
"localid@host". Call-IDs are case-sensitive and are simply compared
byte-by-byte.

Using cryptographically random identifiers provides some
protection against session description can be used to accommodate hijacking, and reduces the
capabilities
likelihood of new arrivals to a conference, add or delete media unintentional Call-ID collisions.

No provisioning or
change from a unicast to a multicast conference.)

If an INVITE request human interface is required for an existing session fails, the session
description agreed upon in selection of
the last successful INVITE transaction
remains in force.

A UAC MUST NOT issue another INVITE request Call-ID header field value for a request.

For further information on the same call leg
before the previous INVITE transaction has completed. A UAS that
receives an INVITE before it sent the final response Call-ID header see Section 22.8.

Example:

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

8.1.1.4 CSeq

Various Authors [Page 27]

Internet Draft SIP October 26, 2001

The Cseq header serves as a way to an INVITE
with identify and order transactions.
It consists of a lower CSeq sequence number on and a method. The method MUST match
that of the same call leg request. The sequence number value is arbitrary, but MUST return
be expressible as a 400 (Bad
Request) response 32-bit unsigned integer and MUST include be less than
2**31.

As long as it follows the above guidelines, a Retry-After client may use any
mechanism it would like to select CSeq header field with a
randomly chosen value of between 0 and 10 seconds.

If a UA A sends an values.

For further information on the CSeq header see Section 22.16.

Example:

CSeq: 4711 INVITE request

8.1.1.5 Via

The Via header is used to B determine the transport to use for sending
a request, and receives an INVITE request
from B before it has received for identifying the IP address and port where the
response is to its request from B, A
MAY return a 500 (Internal Server Error), which SHOULD include a
Retry-After be sent. Rules for setting and using the values in
this header field specifying when are described in Section 19.

For further information on the request should be
resubmitted.

In most cases, Via header see Section 22.40.

8.1.1.6 Contact

The Contact header provides a UA SIP URI that can assume be used to contact
that specific instance of the order user agent for subsequent requests. The
Contact header MUST be present in any request that can result in the
establishment of messages
received corresponds to a dialog. For the order they were sent. In rare
circumstances, methods defined in this
specification, that includes only the response from B and INVITE request. For these
requests, the request from B
may be reordered on scope of the wire.

In addition, if A or B change multicast addresses, strict transaction
ordering Contact is necessary so the dialog. That is, the
Contact header refers to the URL that both sides agree on the final result.

A UAC MUST be prepared UA would like to receive media data according to the session
description as soon as it sends an INVITE (or re-INVITE) and can
start sending media data when it receives a provisional or final
response containing
requests at, for requests that are part of that dialog only. Only a session description.
single URI MUST be present.

For further information on the Contact header, see Section 22.10.

8.1.1.7 Request-URI

The initial INVITE from Request-URI of the UAC message SHOULD contain be set to the Allow and
Supported header fields, and MAY contain value of
the Accept header URI in the To field. A
200 (OK) response to One notable exception is the initial INVITE REGISTER
method; behavior for a call SHOULD contain setting the
Allow and Supported header fields, and MAY contain Request-URI of register is given in
Section 10. Another exception is the Accept header
field.

Handley/Schulzrinne/Schooler/Rosenberg case of pre-existing Route
headers; in that case, the procedures of Section 12.2.1.1 as they

Various Authors [Page 33] 28]

Internet Draft SIP July 20, October 26, 2001

Including these header fields allows the UAC

pertain to determine the features Request- URI are followed, even though there is no
dialog.

8.1.1.8 Supported and Require

If the UAC supports extensions supported to SIP that can be applied by the UAS for
server to the
duration of response, the UAC SHOULD include a Supported header in
the call, without probing.

This method MUST be supported by SIP proxy, redirect and user agent
servers as well as clients.

5.1.1 ACK

The ACK request confirms that listing the client has received a final
response option tags for those extensions.

The option-tags listed MUST only refer to an INVITE request. (ACK extensions defined in
standards track RFCs. This is used only with INVITE
requests.) Treatment of ACK for a 200 class response differs
significantly to prevent servers from insisting that of a non-200 class response. 2xx responses
are acknowledged by client user agents, all other final responses by
the first stateful proxy or client user agent
clients implement non-standard, vendor defined features in order to
receive service. Extensions defined by experimental and informational
RFCs are explicitly excluded from usage with the
response. The Via is always initialized Supported header in
a request, since they too are often used to document vendor defined
extensions.

If the host UAC wishes to insist that originates
the ACK request, i.e., the client user agent after a 2xx response or UAS understand an extension that
the first proxy or UAC will apply to receive a non-2xx final response. For a
non-200 class response, the Via request in order to process the ACK that is constructed request, it
MUST
be the same as insert a Require header into the request being acknowledged. The ACK for a 200
class response will contain Route headers if Record-Route headers
were present in listing the response. An ACK option tag
for that extension. If the UAC wishes to apply an extension to the
request and insist that a non-200 class response
never contains Route headers. The ACK proxy understand that extension, it MUST
insert a Proxy-Require header into the request listing the option tag
for that extension.

8.1.1.9 Additional Message Components

After a 200 class
response is forwarded new request has been created, the headers described above
have been properly constructed, any additional optional headers are
added, as are any headers specific to the corresponding INVITE request, based on
its Request-URI or Route headers, and thus method.

SIP requests MAY take contain a different path
than MIME-encoded message-body. Regardless of
the original INVITE request, and MAY even cause type of body that a new transport
connection to request contains, certain headers must be opened in order
formulated to send it. characterize the contents of the body. For further
information on these headers see Section 7.4.

8.1.2 Sending the Request

The Request-URI destination for the
ACK request is set then computed. This can be a
preconfigured IP address, port and transport of an outbound proxy, or
it can be determined through DNS procedures applied to the top entry Request-
URI. These procedures are described in the route Section 24, which yield an
ordered set of address, port and transports to attempt. The UAC
SHOULD follow the procedures defined there for stateful elements,
trying each address until a 200 class response
(see Section 16). For server is contacted. Each try constitutes
a non-200 class response, the Request-URI new transaction, and therefore a new client transaction MUST be
constructed for each.

Various Authors [Page 29]

Internet Draft SIP October 26, 2001

8.1.3 Processing Responses

Responses are first processed by the same as the Request-URI in transport layer, and then passed
up to the request being acknowledged. transaction layer. The ACK request does not generate responses for any transport
protocol. transaction layer performs its
processing, and then passes it up to the TU. The ACK request for a 200 class majority of response MAY contain a message body
with
processing in the final session description TU is method specific. However, there are some
general behaviors independent of the method.

8.1.3.1 Unrecognized Responses

A UAC MUST treat any response they do not recognize as being
equivalent to the x00 response code of that class, and MUST be used by able
to process the callee. See
Section 5.1 x00 response code for further details on the relationship between session
descriptions in INVITE and ACK requests.

A proxy server receiving an ACK request after having sent all classes. For example, if a 3xx, 4xx,
5xx, or 6xx
UAC receives an unrecognized response must make a determination about whether the ACK
is for it, or for some user agent or proxy server further downstream.
This determination is made by examining the tag in code of 431, it can safely
assume that there was something wrong with its request and treat the To field.
response as if it had received a 400 (Bad Request) response code.

8.1.3.2 Vias

If
the tag more than one Via header field is present in a response, the ACK To UAC
SHOULD discard the message.

The presence of additional Via header field matches fields that precede
the tag originator of the request suggests that the message was
misrouted or possibly corrupted.

8.1.3.3 Processing 3xx responses

Upon receipt of a redirection response (e.g. a 3xx response status
code), clients SHOULD use the URI(s) in the To Contact header field of to
formulate a new request.

To do that, the response, and client copies all but the From, CSeq "method-param" and Call-ID "header"
elements of the addr-spec part of the Contact header fields
in field into the response match those in
Request-URI of the ACK, request. It uses the ACK is meant "header" parameters to create
headers for the
proxy server. Otherwise, request, replacing any default headers normally used.

In all other respects, requests sent upon receipt of a redirect
response SHOULD re-use the ACK headers and bodies of the original
request.

The Contact values present in redirection responses SHOULD NOT be proxied downstream
cached across calls, as any
other request. However, an ACK they may not destined for represent the proxy SHOULD NOT

Handley/Schulzrinne/Schooler/Rosenberg most desirable
location for a particular destination address.

8.1.3.4 Processing 4xx responses

Certain 4xx response codes require specific UA processing,

Various Authors [Page 34] 30]

Internet Draft SIP July 20, October 26, 2001

be retransmitted.

It is possible for

independent of the method.

If a user agent client 401 or proxy server to
receive multiple 3xx, 4xx, 5xx, 407 response is received, the UAC SHOULD follow the
authorization procedures of Section 20.2.2 and 6xx responses Section 20.2.3 to a
retry the request along a single branch. This can happen under
various error conditions, typically when with credentials.

If a forking proxy
transitions from stateful to stateless before receiving all
responses. The various responses will all be identical,
except for the tag in the To field, which 413 response is different for
each one. It can therefore be used as a received (Section 23.4.11), it means to
disambiguate them.

This method MUST be supported by SIP user agents.

5.2 CANCEL

The CANCEL that the
request cancels contained a pending request with body that was longer than the same Call-ID,
To, From, top Via header and Request-URI and CSeq (sequence number
only) header field values, but does not affect a completed request or
existing calls. (A request is considered completed if UAS was willing to
accept. If possible, the server has
returned a final status response.) The UAC can use a BYE request to
terminate a call if SHOULD retry the CANCEL arrived too late.

A user agent client request, either
omitting the body or proxy client MAY issue a CANCEL request at any
time. A proxy client SHOULD generate using one of a CANCEL request for branches
without smaller length.

If a final 415 response after is received (Section 23.4.13), it has forked a means the request and receives a
2xx or 6xx response from one of
contained media types not supported by the branches. A UAS. The UAC or proxy client SHOULD send a CANCEL if retry
sending the request, this time noted only using content with types listed
in the Expires Accept header of in the
request has elapsed or no provisional or final response was received
after a client-determined timeout interval. Finally, internal logic
such as scripts, MAY trigger CANCEL requests.

A stateful proxy that receives a CANCEL request immediately responds response, with a 200 class encodings listed in the
Accept-Encoding header in the response, and with languages listed in
the Accept-Language in the response. It then generates

If a new CANCEL, and
forwards 420 response is received (Section 23.4.14), it means the request to all destinations with pending requests. A
stateless proxy,
contained a Require or Proxy-Require header listing an option-tag for
a feature not supported by a stateful proxy with no transaction state for or UAS. The UAC SHOULD retry the cancelled
request, proxies the CANCEL request to the same set of
destinations the original request was proxied to.

The Request-URI, topmost Via, Call-ID, To, this time omitting any extensions listed in the numeric part of CSeq
and From Unsupported
header fields in the CANCEL request are identical to those
in response.

In all of the above cases, retrying the original request being cancelled, including tags. This allows is accomplished by
creating a CANCEL new request to be matched with the appropriate modifications. This new
request it cancels. However,
to allow SHOULD have the client to distinguish responses to same value of the CANCEL from those
to Call-ID, To, and From of
the original previous request, but the CSeq Method component is set to CANCEL.
The Via header field should contain a new sequence
number that is initialized to one higher than the proxy issuing previous.

With other 4xx responses, a retry may or may not be possible
depending on the CANCEL
request. (Thus, responses to this CANCEL request only reach method and the

Handley/Schulzrinne/Schooler/Rosenberg [Page 35]

Internet Draft SIP July 20, 2001

issuing proxy.)

The behavior use case.

8.2 UAS Behavior

When a request outside of a dialog is processed by a UAS, there are a
set of processing rules which are followed, independent of the user agent or redirect server
method. Section 12 gives guidance on receiving how a
CANCEL request depends on UAS can tell whether a
request is inside or outside of a dialog.

8.2.1 Authentication/Authorization

A UAS MAY authenticate the originator of a request, and this process
may require the server has already sent to issue a final
response challenge for credentials. The
required behavior is independent of the original request. If it has, method of the CANCEL request, and is
detailed in Section 20.2.

8.2.2 Method Inspection

Various Authors [Page 31]

Internet Draft SIP October 26, 2001

Once a request has is authenticated (or no effect on authentication was desired),
the original request, any call state and on UAS MUST inspect the
responses generated for method of the original request. If the server has UAS does not
issued a final response for the original request, it immediately
responds to
support the original method of a request with it MUST generate a 487 (Request Terminated),
following normal rules 405 (Method Not
Allowed) response. Procedures for response retransmissions defined generation of responses are
described in Section 14. For INVITE requests, the UAC as usual sends 8.2.7. The UAS MUST also add an ACK
request Allow header to confirm receipt of any final
the 405 response. The CANCEL request
itself is answered with a 200 (OK) response in either case. If Allow header field MUST list the
UAS or redirect server has no record set of methods
supported by the request being cancelled, UAS generating the CANCEL message.

The Allow header is responded to with a 481.

A proxy client or UAC cannot rely on receiving a 487 (Request
Terminated) response, as presented in Section 22.5.

If the method is one supported by the server, processing continues.

8.2.3 Header Inspection

If a RFC 2543-compliant UAS will does not generate
such understand a response. If there has been no final response after 32
seconds, the client MAY consider the original transaction to have
been cancelled.

The BYE request cannot be used to cancel branches of header field in a
parallel search, since several branches may, through
intermediate proxies, find request (i.e. the
header is not defined in this specification or in any supported
extension), the same user agent server MUST ignore that header and
then terminate continue
processing the call. message. A UAS SHOULD ignore any malformed headers
which are not necessary for processing requests.

8.2.3.1 To terminate a call instead of
just pending searches, and Request-URI

The To header field identifies the UAC must use BYE instead original recipient of or
in addition to CANCEL. While CANCEL can terminate any
pending the request other than ACK or CANCEL, it is typically
useful only for INVITE. 200 responses to INVITE and 200
responses to CANCEL can be distinguished
designated by the method user identified in the Cseq header From field.

This method MUST be supported by proxy servers and SHOULD be
supported by all other SIP server types.

6 BYE The user agent client uses BYE to indicate to original
recipient may or may not be the server that it
wishes to release UAS processing the request, do to
call leg. A BYE request is forwarded like an
INVITE request and MAY be issued by either caller forwarding or callee. other proxy operations. A BYE
request SHOULD NOT be sent UAS MAY apply any policy
it wishes in determination of whether to terminate accept requests when the To
field is not the identity of the UAS. However, it is RECOMMENDED that
a pending call request which
has UAS accept requests even if they do not generated either recognize the URI scheme
(e.g., a final response tel: URI) in the To header, or a provisional response
containing a if the To tag. A party to header does not
address a call known or current user of this UAS. If, on the other hand,
the UAS decides to reject the request, it SHOULD issue a BYE request
before releasing generate a call ("hanging up"). A party receiving response
with a BYE
request MUST cease transmitting media streams specifically directed
at 403 status code and send it to the party issuing server transaction for
transmission.

However, the Request-URI identifies the UAS that is to process the BYE
request.

Handley/Schulzrinne/Schooler/Rosenberg [Page 36]

Internet Draft SIP July 20, 2001

A If the Request-URI does not identify an address that the UAS receiving a BYE request MUST respond
is willing to any pending accept requests
received for, it SHOULD reject the request with
a 404 (Not Found) response. If the Request-URI does not provide
sufficient information for that call, including INVITE. It the UAS to determine whether it is RECOMMENDED that willing
to process the request, it SHOULD return a
487 response is generated. 485 (Ambiguous) response.
This method response SHOULD contain a Contact header field containing URIs
of new addresses to be supported by user agent servers.

7 Registrars, Registrations and the REGISTER Method

A client tried.

Typically, a UA which uses the REGISTER method to bind the its address listed in the
To header field with a SIP server of
record to one or more URIs where a specific contact address, will see requests whose
Request-URI equals those contact addresses.

Various Authors [Page 32]

Internet Draft SIP October 26, 2001

8.2.3.2 Require

Assuming the
client can be reached, contained in UAS decides that it is the Contact header fields. These
URIs may use any URI scheme, not limited proper element to SIP.

It process the
request, it examines the Require header field, if present.

The Require general-header field is particularly important used by UAC to tell UAS about SIP
extensions that REGISTER requests are authenticated
since they allow the UAC expects the UAS to redirect future requests (see Section 18.2).

7.1 Where support in order to Register

A user agent
properly process the request. If a UAS does not understand an option
listed in a Require header field, it MUST respond by generating a
response with status code 420 (Bad Extension). The UAS MUST add a
Unsupported, and list in it those options it does not understand
amongst those in the Require header of the request. Upon receipt of
the 420 the client SHOULD attempt to register periodically according to retry the
rules below. A UA request, this time without using
those extensions listed in the Unsupported header in the response.

Example:

UACC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: com.example.billing
Payment: sheep_skins, conch_shells

UASS->UAC: SIP/2.0 420 Bad Extension
Unsupported: com.example.billing

This is said to be "visiting" if its From address domain
differs from make sure that the current network domain client-server interaction
will proceed without delay when all options are understood
by both sides, and is said to be "at home" only slow down if the two options are not
understood (as in the same.

Local server: If an outbound proxy is configured, the UA SHOULD
send example above). For a REGISTER request to it. If well-matched
client-server pair, the UA is visiting, interaction proceeds quickly,
saving a round-trip often required by negotiation
mechanisms. In addition, it
uses also removes ambiguity when the From address consisting
client requires features that the server does not
understand. Some features, such as call handling fields,
are only of interest to end systems.

8.2.4 Content Processing

Assuming the URL-escaped user
identity at UAS understands any extensions required by the visited domain, e.g., client,
the user identified
as alice@wonderland.com would register as
alice%40wonderland.com@example.com if she is visiting UAS examines the
example.com domain.

Multicast: body of the message, and the headers that
describe it. If no local outbound proxy is configured, multicast
registrations there are addressed to the well-known "all SIP
servers" multicast address "sip.mcast.net" (224.0.1.75).
This request MUST be scoped to ensure it is not forwarded
beyond any bodies whose type (indicated by the boundaries of
Content-Type), language (indicated by the administrative system. This
MAY be done with either TTL Content-Language) or administrative scopes [28],
depending on what is implemented in
encoding (indicated by the network. SIP user
agents MAY listen to that address Content-Encoding) are not understood, and use it to become
aware of the location of other local users [18]; however,
they do
that body part is not respond to optional (as indicated by the request.

Multicast registration may be inappropriate in some
environments, for example, if multiple businesses
share Content-
Disposition) header, the same local area network.

Home server: If UAS MUST reject the UA is visiting, it SHOULD also send request with a 415
(Unsupported Media Type) response. The response MUST contain a

Handley/Schulzrinne/Schooler/Rosenberg Accept

Various Authors [Page 37] 33]

Internet Draft SIP July 20, October 26, 2001

registration to its home SIP server, identified by its home
address. For example, alice@wonderland.com would send a
registration to the SIP server for the domain
wonderland.com when she is visiting another network. TBD:
What Contact should be used?

A user agent SHOULD register with a local server on startup and
periodically thereafter by sending a REGISTER request. The period is
given by the expiration time indicated in the registration response.
It is RECOMMENDED that the UA registers via multicast and send a
registration to its "home" address, i.e., the server for

header listing the domain
that types of all bodies it uses as its From address understands, in outgoing requests.

7.2 REGISTER Header Fields

Request-URI: The Request-URI names the destination of the
registration request, i.e., event
the domain request contained bodies of types not supported by the registrar.
The user name MUST be empty. Generally, UAS. If
the domains in request contained content encodings not understood by the
Request-URI and UAS,
the To response MUST contain an Accept-Encoding header field have listing the same value;
however, it is possible to register as a "visitor", while
maintaining one's name. For example, a traveler
sip:alice@acme.com (To) might register under
encodings understood by the Request-
URI sip:atlanta.hiayh.org , UAS. If the request contained content
with languages not understood by the former as UAS, the To response MUST contain
an Accept-Language header field and indicating the latter as languages understood by the Request-URI. The
REGISTER request
UAS.

Beyond these checks, body handling is no longer forwarded once it has reached method and type specific.

For further information on the server whose authoritative domain is processing of Content-specific headers
see Section 7.4.

8.2.5 Applying Extensions

A UAS that wishes to apply some extension when generating the one listed
response MUST only do so if support for that extension is indicated
in the Request-URI.

Call-ID: All registrations from a client SHOULD use the same
Call-ID Supported header value, at least within in the same reboot
cycle.

Cseq: Registrations with request. If the same Call-ID MUST have increasing
CSeq header values. However, desired extension is
not supported, the server does not reject
out-of-order requests.

7.3 Registering Contact Locations

REGISTER requests are processed in SHOULD rely only on baseline SIP and any
other extensions supported by the client. To ensure that the order received. Clients SHOULD
avoid sending
can be fulfilled, any specification of a new registration (as opposed extension MUST include
discussion of how to a retransmission)
until they have received gracefully return to baseline SIP when the response from
extension is not present. In rare circumstances, where the server for the
previous one.

Clients may register from different locations, by necessity
using different Call-ID values. Thus, the CSeq value
cannot
be used to enforce ordering. Since registrations are
additive, ordering is less of a problem than if each

Handley/Schulzrinne/Schooler/Rosenberg [Page 38]

Internet Draft SIP July 20, 2001

We define "address-of-record" as without the SIP address that extension, the registry
knows server MAY send
a 421 (Extension Required) response. This response indicates that the registrand, typically
proper response cannot be generated without support of the form "user@domain" rather than
"user@host". In third-party registration, the entity issuing the
request is different from the entity being registered.

To: a specific
extension. The To needed extension(s) MUST be included in a Require
header field contains in the address-of-record whose
registration response. This behavior is NOT RECOMMENDED, as it will
generally break interoperability.

Any extensions applied to a non-421 response MUST be created or updated.

From: The From listed in a
Require header field contains included in the address-of-record of response. Of course, the person responsible for server MUST
NOT apply extensions not listed in the registration. For first-
party registration, it is identical to the To Supported header field
value. It is RECOMMENDED that registrars authorize whether
the entity in the From field is allowed to register
addresses for the address-of-record in the To field.

Contact: The request MAY contain
request. As a Contact header field. Future
non-REGISTER requests for the URI given in result of this, the To Require header
field SHOULD be directed to the address(es) given in the
Contact header.

If the request does not contain a Contact header, the
registration remains unchanged.

This is useful to obtain the current list of
registrations response will
only ever contain option tags defined in standards track RFCs.

8.2.6 Processing the response, as described below.

If a SIP URI in a registration Contact header field differs
from existing registrations according to Request

Assuming all of the rules checks in
Section 2.1, it is added to the list of registration. If it
is equivalent, according to these rules, to an existing
registration, all Contact header field parameters for this
entry are updated accordingly. URIs other than SIP URIs previous subsections are
compared according to passed,
the standard URI equivalency rules
for UAS processing becomes method specific. Section 10 deals with the URI schema.

All current registrations MUST share
REGISTER request, section 11 deals with the same action value.
Registrations that have a different action than current
registrations for OPTIONS request, section
13 deals with the same user MUST be rejected INVITE request, and section 15 deals with
status of 409 (Conflict).

A proxy server ignores the q parameter when processing
non-REGISTER requests, while BYE
request.

8.2.7 Generating the Response

When a UAS wishes to construct a redirect server simply
returns that parameter in its Contact response header
field.

Handley/Schulzrinne/Schooler/Rosenberg to a request, it follows

Various Authors [Page 39] 34]

Internet Draft SIP July 20, October 26, 2001

Having the proxy server interpret the q parameter is
not sufficient to guide proxy behavior, as it is not
clear, for example, how long it is supposed to wait
between trying addresses.

If the registration is changed while a user agent or proxy server
processes an invitation, the new information SHOULD

these procedures. Additional procedures may be used.

7.4 Registration Expiration

An optional "expires" Contact parameter indicates needed depending on
the desired
expiration time status code of the registration. If a Contact entry does not have
an "expires" parameter, the Expires request and response header field
is used as and the default value. If neither circumstances of these mechanisms is used,
SIP URIs its
construction. These additional procedures are assumed to expire after one hour. Other URI schemes have
no expiration times. Registrations not refreshed after this amount documented elsewhere.

The From field of
time SHOULD be silently discarded.

In a REGISTER request, the client indicates how long it wishes the
registration to be valid. In the response, the server indicates response MUST equal the
earliest expiration time From field of all registrations. If a registration
updates an existing registration, the Expires value
request. The Call-ID field of the most
recent registration is used, even if it is shorter than response MUST equal the earlier
registration. Call-ID
field of the request. The registrar determines Cseq field of the expiration time; it may be longer or
shorter than response MUST equal the one requested by
Cseq field of the registrand. request. The REGISTER
response contains the actual registration lifetime; Via headers in the client response MUST
refresh at least as often and SHOULD NOT refresh more frequently. In
general, equal
the server SHOULD honor Via headers in the expiration time offered by request, and MUST maintain the
user agent. A server MAY decide to lengthen the expiration interval
if, for example, the refresh rate of same ordering.

If a particular client exceeds request contained a
threshold.

This behavior is different from RFC 2543, which only allowed
registrars to decrease, but not increase, the interval.

Allowing To tag in the registrar to set request, the registration interval
protects it against excessively frequent registration
refreshes while limiting To field in the state
response MUST equal that it needs to
maintain and decreasing of the chance for stale registrations
that require proxying effort.

Registration refreshes SHOULD be sent to request. However, if the same address as To field in
the
original registration, unless redirected.

7.5 List of Current Registrations

Handley/Schulzrinne/Schooler/Rosenberg [Page 40]

Internet Draft SIP July 20, 2001

2xx REGISTER responses SHOULD list all current registration request did not contain a tag, the URI in the
Contact header field. An "expires" parameter To field in the
response MUST indicate equal the
expiration time of URI in the registration.

7.6 Removing Registrations

Registrations expire as described above or may be removed explicitly
by setting To field in the expires parameter for an existing registration to zero
or including an Expires: 0 header field. Registrations are matched
based on request.
Additionally, the user, host, port and maddr parameters. A client can
remove all registrations by including UAS MUST add a single Contact header tag to the To field
with in the wildcard address "*". response.
This usage serves to identify the UAS that is only allowed responding, possibly
resulting in REGISTER
requests when a Expires header with value of zero is present.

Support component of this method is RECOMMENDED; registrars MUST support it.

8 OPTIONS a dialog ID. The OPTIONS method is same tag MUST be used
for all responses to query a server as to its capabilities.
A server that believes request, both provisional and final.
Procedures for generation of tags are defined in Section 21.3.

8.3 Redirect Servers

In some architectures it can contact may be desirable to reduce the user, such as processing
load on proxy servers that are responsible for routing requests by
relying on redirection. Redirection allows servers to push routing
information for a user agent
where the user is logged request back in and has been recently active, MAY respond a response to the client, thereby
taking themselves out of the loop of further messaging for this
transaction while still aiding in locating the target of the request.
When the originator of the request with a capability set. A called user agent MAY return receives the redirection it will
send a status reflecting how new request based on the routing information it would have responded has received.
By propagating routing information from the core of the network to an invitation,
e.g., 600 (Busy).
its edges, redirection allows for considerable network scalability.

A redirect server SHOULD return Allow, Accept, Accept-
Encoding, Accept-Language is logically constituted of a server transaction
layer and Supported header fields. The response
MAY contain a message body indicating the capabilities of the end
system (rather than properties of any existing call).

The use transaction user that has access to a location service of the Call-ID header field is discussed in
some kind (see Section 10.12. An
OPTIONS requests 10 for an existing call-id has no impact more on that call.

This method MUST be supported by SIP user agents registrars and registrars.

9 Response

After receiving location
services). This location service is effectively a database containing
mappings between a single URI and interpreting a request message, set of one or more alternative
locations at which the recipient
responds with a SIP response message. The response message format is
shown below:

Response = Status-Line ; Section 9.1
*( general-header
| response-header
| entity-header )
CRLF
[ message-body ] ; Section 12

Handley/Schulzrinne/Schooler/Rosenberg [Page 41]

Internet Draft SIP July 20, 2001

SIP's structure target of responses is similar to [H6], but is defined
explicitly here.

9.1 Status-Line

The first line that URI can be found.

A redirect server does not issue any SIP requests of its own. After
receiving a Response message is request other than CANCEL, the Status-Line, consisting
of server gathers the protocol version (Section 4.3.1) followed by a numeric
Status-Code and its associated textual phrase, with each element
separated by SP characters. No CR or LF is allowed except in list of
alternative locations from the
final CRLF sequence.

Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF

9.1.1 Status Codes location service and Reason Phrases

The Status-Code is either returns a 3-digit integer result code that indicates the
outcome
final response of the attempt to understand and satisfy class 3xx or it refuses the request. The
Reason-Phrase is intended to give For well-
formed CANCEL requests, it SHOULD return a short textual description of 2xx response. This
response ends the
Status-Code. SIP transaction. The Status-Code is intended for use by automata, whereas
the Reason-Phrase is intended redirect server maintains
transaction state for the human user. The client is not
required to examine or display the Reason-Phrase.

We provide an overview of the Status-Code below, and provide full
definitions in Section 11. The first digit of the Status-Code defines entire SIP transaction. It is the class
responsibility of response. The last two digits do not have any
categorization role. SIP/2.0 allows 6 values for the first digit:

1xx: Informational -- request received, continuing clients to process
the request;

2xx: Success -- the action was successfully received,
understood, and accepted;

Handley/Schulzrinne/Schooler/Rosenberg detect forwarding loops between redirect

Various Authors [Page 42] 35]

Internet Draft SIP July 20, October 26, 2001

3xx: Redirection -- further action needs to be taken in order

servers.

When a redirect server returns a 3xx response to
complete the request;

4xx: Client Error -- a request, it
populates the request contains bad syntax list of (one or cannot
be fulfilled at this server;

5xx: Server Error -- the server failed more) alternative locations into
Contact headers. An "expires" parameter to fulfill an apparently
valid request;

6xx: Global Failure -- the request cannot Contact header may
also be fulfilled at any
server.

Figures 4 through 8 present supplied to indicate the individual values lifetime of the numeric Contact data.

The Contact header field contains URIs giving the new locations or
user names to try, or may simply specify additional transport
parameters. A 301 or 302 response codes, and an example set of corresponding reason phrases
for SIP/2.0. These reason phrases are only recommended; they may be
replaced by local equivalents without affecting also give the protocol. Note same location and
username that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response
codes in was targeted by the range starting at x80 initial request but specify
additional transport parameters such as a different server or
multicast address to avoid conflicts with newly
defined HTTP response codes, and adds try, or a new class, 6xx, change of response
codes.

SIP response codes are extensible. SIP applications are not required transport from UDP to understand the meaning of all registered response codes, though
such understanding is obviously desirable. However, applications MUST
understand the class of any response code, as indicated by
TCP or vice versa.

Note that the first
digit, and treat any unrecognized response as being equivalent Contact header field MAY also refer to a different
entity than the
x00 response code of that class. However, proxies SHOULD distinguish
100 from other 1xx responses. (The former SHOULD NOT be forwarded,
while the latter MUST be. See Section 17.3.) one originally called. For example, if a
client receives an unrecognized response code of 431, it can safely
assume that there was something wrong with its request and treat the
response as if it had received a 400 (Bad Request) response code. In
such cases, user agents SHOULD present to the user the message body
returned with the response, since that message body is likely to
include human-readable information which will explain the unusual
status.

10 Header Field Definitions SIP header fields are similar call
connected to HTTP header fields in both syntax
and semantics. In particular, SIP header fields follow the syntax for
message-header GSTN gateway may need to deliver a special informational
announcement such as described in [H4.2]. The rules for extending "The number you have dialed has been changed."

A Contact response header
fields over multiple lines, and use of multiple message-header fields

Handley/Schulzrinne/Schooler/Rosenberg [Page 43]

Internet Draft SIP July 20, 2001

Informational = "100" ; Trying
| "180" ; Ringing
| "181" ; Call Is Being Forwarded
| "182" ; Queued
| "183" ; Session Progress
Success = "200" ; OK

Figure 4: Informational and success status codes

Redirection = "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "305" ; Use Proxy
| "380" ; Alternative Service

Figure 5: Redirection status codes

with field can contain any suitable URI
indicating where the same field-name, described in [H4.2] also apply to SIP. The
rules in [H4.2] regarding ordering of header fields apply to SIP.

The header fields required, optional and called party can be reached, not applicable for each
method are listed in Table 4 and Table 5. The table uses "o" limited to
indicate optional, "m" mandatory and "-" SIP
URIs. For example, it could contain URL's for not applicable.
"Optional" means that phones, fax, or irc (if
they were defined) or a UA MAY include mailto: (RFC 2368, [18]) URL.

The "expires" parameter of the Contact header field in indicates how
long the URI is valid. The parameter is either a request number indicating
seconds or response, and a UA MAY ignore quoted string containing a SIP-date. If this parameter
is not provided, the value of the Expires header field if present in determines how
long the
request URI is valid. Implementations MAY treat values larger than
2**32-1 (4294967295 seconds or response. A "mandatory" request header field MUST be
present in a request, and 136 years) as equivalent to 2**32-1.

Redirect servers MUST be ignore features that are not understood by
(including unrecognized headers, Required extensions, or even method
names) and proceed with the UAS receiving redirection of the
request. A mandatory response header field session in question.
If a particular extension requires that intermediate devices support
it, the extension MUST be present tagged in the
response, and the header Proxy-Require field MUST be understood by the UAC as well
(see Section 22.28).

9 Canceling a Request

The previous section has discussed general UA behavior for generating
requests, and processing the response. "Not applicable" means responses, for request header
fields that the header field MUST NOT be present in requests of all methods. In
this section, we discuss a request. If one general purpose method, called CANCEL.

The CANCEL request, as the name implies, is placed in used to cancel a previous
request sent by mistake, a client. Specifically, it MUST be ignored by asks the UAS
receiving user agent server
to cease processing the request, and generate an error response to

Various Authors [Page 36]

Internet Draft SIP October 26, 2001

that request. Similarly, CANCEL has no effect on a header field labeled "not
applicable" request that has already been
responded to. Because of this, it is most useful to CANCEL requests
which can take a long time to respond to. For this reason, CANCEL is
most useful for INVITE requests, which can take a response means long time to
generate a response. In that the usage, a UAS MUST NOT place that receives a CANCEL
request for an INVITE, but has not yet sent a response, would "stop
ringing", and then respond to the INVITE with a specific error
response (a 487).

Cancel requests can be constructed and sent by any type of client,
including both proxies and user agent servers. Section 15 discusses
under what conditions a UAC would CANCEL an INVITE request, and
Section 16 discusses proxy usage of INVITE.

Because a stateful proxy can generate its own CANCEL, a stateful
proxy also responds to a CANCEL, rather than simply forwarding a
response it would receive from a downstream element. For that reason,
CANCEL is referred to as a "hop-by-hop" request, since it is
responded to at each stateful proxy hop.

9.1 Client Behavior

The following procedures are used to construct a CANCEL request. The
Request-URI, Call-ID, To, the numeric part of CSeq and From header
fields in the response, and CANCEL request MUST be identical to those in the UAC
request being cancelled, including tags. A CANCEL constructed by a
client MUST ignore have only a single Via header, whose value matches the header
top Via in the
response. "m*" request being cancelled. Using the same values for
these headers allows the CANCEL to be matched with the request it
cancels (Section 9.2 indicates a how such matching occurs). However,
the method part of the Cseq header that SHOULD be sent, but servers
need MUST have a value of CANCEL. This
allows it to be prepared identified and processed as a transaction in its own
right (See Section 17).

Once the CANCEL is constructed, the client SHOULD check whether any
response (provisional or final) has been received for the request
being cancelled (herein referred to receive messages without that header field. A
"*" indicates that as the header fields are required "original request"). The
CANCEL request MUST NOT be sent if no provisional response has been
received, rather, the message body
is not empty. See sections 10.18, 10.19 and 12 client MUST wait for details.

Handley/Schulzrinne/Schooler/Rosenberg [Page 44]

Internet Draft SIP July 20, 2001

Figure 6: Client error status codes

Figure 7: Server error status codes

The "where" column describes the request and arrival of a
provisional response types with
which before sending the header field can be used. "R" refers to header fields that
can be used in requests (that is, request. If the original
request and general header fields).

Handley/Schulzrinne/Schooler/Rosenberg [Page 45]

Internet Draft SIP July 20, 2001

Global-Failure = "600" ; Busy Everywhere
| "603" ; Decline
| "604" ; Does not exist anywhere
| "606" ; Not Acceptable

Figure 8: Global failure status codes

"r" designates has generated a response or general-header field final response, the CANCEL SHOULD NOT be
sent, as applicable it is an effective no-op, since CANCEL has no effect on
requests which have already generated a final response. When the
client decides to
all responses, while send the CANCEL, it creates a list of numeric values indicates client transaction
for the status
codes CANCEL, and passes it the CANCEL request along with which the header field can be used. "g"
destination address, port and "e" designate
general (Section 10.1) transport. The destination address,
port, and entity header (Section 10.2) fields,
respectively. If a header field is marked "c", it is copied from transport for the
request CANCEL MUST be identical to those used to
send the response.

The "proxy" column describes whether proxies can add comma-separated
elements original request.

Various Authors [Page 37]

Internet Draft SIP October 26, 2001

If it was allowed to headers ("c", send the CANCEL before receiving a
response for concatenate or comma), can modify the
header ("m"), can add previous request the header if not present ("a") or need to read server could receive
the header ("r"). Headers that need to be read cannot be encrypted.
Proxies MUST NOT alter any fields that are authenticated (see Section
18.2), but MAY add copies of fields CANCEL before the original request.

Note that were authenticated by both the UA
if indicated in transaction corresponding to the table. Depending on local policy, proxies MAY
inspect any non-encrypted header fields original request
and MAY modify any non-
authenticated header field, but proxies the CANCEL transaction will complete independently. However, a
UAC canceling a request cannot rely on fields other
than the ones indicated in receiving a 487 (Request
Terminated) response for the table to be readable or modifiable. original request, as an RFC 2543-
compliant UAS will not generate such a response. If authentication there is used, no final
response for the rules original request in Section 18.2 apply. Proxies
SHOULD NOT re-order header fields.

Other header fields can be added as required; 64*T1 seconds for an INVITE
transaction, and T3 seconds for a server MUST ignore
header fields not defined in this specification non-INVITE transaction, the client
SHOULD then consider the original transaction cancelled and SHOULD
destroy the client transaction handling the original request.

9.2 Server Behavior

The CANCEL method requests that it does not
understand. the TU at the server side cancel a
pending request with the same Call-ID, To, From, top Via header and
Request-URI and CSeq (sequence number only) header field values.

The processing of a CANCEL request at a server depends on the type of
server. A stateless proxy MUST NOT remove or modify header fields not
defined in this specification that will forward it, a stateful proxy might
respond to it does not understand. A compact
form and generate some CANCEL requests of these header fields is also defined in its own, and a UAS
will respond to it. See Section 13 16.8 for use
over UDP when proxy treatment of CANCEL.

When a UAS receives a CANCEL, it looks for any server transactions
which were created by requests with the same To, From, Call-ID, Cseq
numeric value, Request-URI and top Via header. If no matching
transactions are found, the CANCEL is responded to with a 481 (Call
Leg/Transaction Does Not Exist). If the transaction for the original
request still exists, the behavior of the UAS on receiving a CANCEL
request depends on whether it has to fit into already sent a single packet final response for
original request. If it has, the CANCEL request has no effect on the
processing of the original request, no effect on any session state,
and size no effect on the responses generated for the original request. If
the UAS has not issued a final response for the original request, it
immediately responds to the original request with a 487 (Request
Terminated).

The CANCEL request itself is
an issue.

Table 6 answered with a 200 (OK) response in Appendix A lists those header fields that different client
and server types MUST be able
either case. Once the response is constructed it is passed to parse. the
server transaction for the CANCEL request.

10 Registrations

10.1 General Header Fields

General header fields apply Overview of Usage

SIP is a protocol that offers a discovery capability. For one user to both request and response messages.

Handley/Schulzrinne/Schooler/Rosenberg

Various Authors [Page 46] 38]

Internet Draft SIP July 20, October 26, 2001

Header field

initiate a session with another, SIP must discover the current
host(s) that the called user is reachable at. This discovery process
is accomplished by SIP proxy servers, which are responsible for
receiving a request, determining where to send it based on knowledge
of the location of the user, and then sending it there. To do this,
proxies consult an abstract service known as a location service ,
which provides address bindings for a particular domain. These
address bindings map an incoming SIP URL, sip:bob@Biloxi.com , for
example, to one or more SIP URLs which are somehow "closer" to the
desired user, sip:bob@engineering.Biloxi.com , for example.
Ultimately, a proxy ACK BYE CAN INV OPT REG
__________________________________________________________
Accept R - o o o o o
Accept 415 - o o o o o
Accept 2xx - - - o o o
Accept-Encoding R - o o o o o
Accept-Encoding 2xx - - - o o o
Accept-Encoding 415 - o o o o o
Accept-Language R - o o o o o
Accept-Language 2xx - - - o o o
Accept-Language 415 - o o o o o
Alert-Info R am - - - o - -
Allow R o o o o o o
Allow 2xx o o o m* m* o
Allow r o o o o o o
Allow 405 m m m m m m
Authorization R o o o o o o
Authorization r o o o o o o
Call-ID gc r m m m m m m
Call-Info g am - - - o o o
Contact R o - - m o o
Contact 1xx - - - o o -
Contact 2xx - - - m o o
Contact 3xx - o - o o o
Contact 485 - o - o o o
Content-Disposition e o o - o o o
Content-Encoding e o o - o o o
Content-Language e o o - o o o
Content-Length e r m* m* m* m* m* m*
Content-Type e * * - * * *
CSeq gc r m m m m m m
Date g will consult a o o o o o o
Encryption g r o o o o o o
Error-Info R o o o o o o
Expires g - - - o - o
From gc r m m m m m m
In-Reply-To R - - - o - -
Max-Forwards R rm o o o o o o
MIME-Version g o o o o o o
Organization g am - - - o o o

Table 4: Summary location service which maps a
received URL to the current host(s) that a user is logged in to.

There are many ways by which the contents of header fields, A--O

The "general-header" field names the location service can
be extended reliably only in
combination with established. One way is administratively. In the above example,
Bob is known to be a change member of the engineering department through
access to a corporate database. SIP provides a mechanism, however,
for a user agent to explicitly create a binding in the protocol version. However, new or
experimental header fields MAY be given location
service of a proxy. This mechanism is known as registration.

The process of registration entails sending a REGISTER message to a
special type of UAS known as a registrar. The registrar acts as a
front end to the semantics location service for a domain, reading and writing
mappings based on the contents of general
header fields if all parties in the communication recognize them REGISTER messages. This
location service will then be consulted by a proxy server that is
responsible for routing requests for that domain.

SIP does not mandate a particular mechanism for implementing the
location service. The only requirement is that a registrar for some
domain MUST be capable of reading and writing data to

Handley/Schulzrinne/Schooler/Rosenberg [Page 47]

Internet Draft the location
service, and a proxy for that domain MUST be capable of reading that
same data. A registrar MAY be co-located with a particular SIP July 20, 2001

Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Priority R
server for the same domain, allowing usage of an in memory database
for the location service. Usage of a - - - o - -
Proxy-Authenticate 401,407 o o o o o o
Proxy-Authorization R r o o o o o o
Proxy-Require R r o o o o o o
Record-Route R amr o o o o o o
Record-Route 2xx,401,484 o o o o o o
Require g acr o o o o o o
Response-Key R - o o o o o
Retry-After 404,413,480,486 o o o o o o
500,503 o o o o o o
600,603 o o o o o o
Route R r o o o o o o
Server r o o o o o o
Subject R - - - o - -
Supported g - o o o o o
Timestamp g o o o o o o
To gc(1) r m m m m m m
Unsupported 420 o o o o o o
User-Agent g o o o o o o
Via gc acmr m m m m m m
Warning r o o o o o o
WWW-Authenticate R o o o o o o
WWW-Authenticate 401 o o o o o o

Table 5: Summary shared database is another
implementation choice. The choice depends entirely on the
architectural requirements (redundancy, scalability, etc) of header fields, P--Z; (1): copied a
particular deployment.

Registration creates bindings in a location service for a particular
domain that associate an "address of record" URI with possible
addition one or more
"contact addresses". This means that when a proxy for that domain
receives a request whose request URI matches the address of tag

be "general-header" fields. Unrecognized header fields are treated as
"entity-header" fields.

10.2 Entity Header Fields

The "entity-header" fields define meta-information about record,
the
message-body or, if no body is present, about proxy will forward the resource identified
by request to the request. The term "entity header" is contact addresses
registered to that address of record. Generally, it only makes sense
to register an HTTP 1.1 term where
the response body can contain address of record at a transformed version location service for a domain
when requests for that address of the message
body. The original message body is referred record would be routed to as that
domain. In most cases, this means that the "entity". We
retain domain of the same terminology for header fields but usually refer registration
will need to match the "message body" rather then the entity as the two are the same domain in
SIP.

10.3 Request Header Fields

The "request-header" fields allow the client to pass additional
information about the request, and about the client itself, to URI of the

Handley/Schulzrinne/Schooler/Rosenberg address of record.

Various Authors [Page 48] 39]

Internet Draft SIP July 20, October 26, 2001

server. These fields act as request modifiers, with semantics
equivalent to the parameters of a programming language method
invocation.

The "request-header" field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics most important usage of "request-
header" fields if all parties in the communication recognize them registration mechanism is to
be request-header fields. Unrecognized header fields are treated as
"entity-header" fields.

10.4 Response Header Fields

The "response-header" fields allow inform a
proxy of the server to pass additional
information about mapping between the response address of record and the current
host on which cannot be placed in the Status-
Line. These header fields give information about UA resides. However, the server registration process is a
general mechanism for establishing bindings, and about
further access to the resource identified by the Request-URI.

Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics used for
other purposes (for example, to set up call forwarding).

10.2 Construction of "response-
header" fields if all parties in the communication recognize them to REGISTER request

Several operations can be "response-header" fields. Unrecognized header fields are treated
as "entity-header" fields.

10.5 Header Field Format

Header fields ("general-header", "request-header", "response-header",
and "entity-header") follow performed with a REGISTER method with
respect to a registrar. One of these is the same generic header format as basic registration
operation that
given in Section 3.1 of RFC 822 [26]. Each header field consists of a
name followed by is described above, which provides a colon (":") new binding
between an address of record and the field value. Field names are
case-insensitive. The field value MAY be preceded by any amount one or more contact addresses.
Registration on behalf of
leading white space (LWS), though a single space (SP) is preferred.
Header fields can particular address of record may be extended over multiple lines
performed by preceding each
extra line with at least one SP a third party if they are authorized to do so. A client
may also remove previous bindings, or horizontal tab (HT). Applications
MUST follow HTTP "common form" when generating these constructs,
since there might exist some implementations that fail query to accept
anything beyond determine which
bindings are currently in place for an address of record.

Aside from the common forms.

message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = < exceptions noted in this and the OCTETs making up following sections,
the field-value
and consisting of either *TEXT-UTF8
or combinations construction of token,
separators, the REGISTER method, and quoted-string>

Handley/Schulzrinne/Schooler/Rosenberg [Page 49]

Internet Draft SIP July 20, 2001

The relative order behavior of header fields with different field names clients
sending a REGISTER is not
significant. Multiple header fields with identical to the same field-name may be
present general UAC behavior described
in a message if Section 8.1 and only if Section 17.1. Regardless of the entire field-value for operation that
header field is defined as
performed by a comma-separated list (i.e., #(values)).
It MUST be possible to combine REGISTER, the multiple following header fields into one
"field-name: field-value" pair, without changing MUST be
formulated as follows:

Request-URI: The Request-URI names the semantics domain of the
message, by appending each subsequent field-value to location
service that the first, each
separated by a comma. registration is meant for (e.g.
"chicago.com"). The order in which user name MUST be empty.

To: The To header fields with field contains the same
field-name are received address of record whose
registration is therefore significant to be created or modified. Note that the
interpretation of the combined
initial To header field value, and thus a proxy MUST NOT
change the order of these Request-URI field values when SHOULD
therefore be different in a message is forwarded.

Unless otherwise stated, parameter names, parameter values and tokens
are case-insensitive. Values expressed as quoted strings are case-
sensitive. REGISTER message.

From: The Contact, From and To header fields contain a URL. If the URL field contains a comma, question mark or semicolon, the URL MUST address of record of
the person responsible for the registration, which MAY be
enclosed in angle brackets (<
identical to the value of the To header field. For third-
party registrations the From header field and >). Any URL parameters To header
field are
contained within these brackets. If the URL is not enclosed in angle
brackets, any semicolon-delimited parameters are header-parameters,
not URL parameters.

10.6 Accept

The Accept header follows the syntax defined in [H14.1]. The
semantics are also identical, with different.

Call-ID: All registrations from a user agent client SHOULD use
the exception that if no Accept same Call-ID header is present, value, at least within the server SHOULD assume a default value of
application/sdp

As a request-header field, it is same
reboot cycle.

If different Call-IDs were used only with those methods that
take message bodies. In a 415 (Unsupported Media Type) response, it
indicates which content types are acceptable in requests. In 200 (OK)
responses for INVITE, it lists the content types acceptable for
future requests in this call.

Example:

Accept: application/sdp;level=1, application/x-private, text/html

10.7 Accept-Encoding

The Accept-Encoding general-header field is similar to Accept, but
restricts overlapping
REGISTER messages coming from the content-codings [H3.5] that are acceptable in same client, the
response. See [H14.3]. The syntax of this header is defined in

Handley/Schulzrinne/Schooler/Rosenberg
registrar might have trouble determining their
ordering.

Various Authors [Page 50] 40]

Internet Draft SIP July 20, October 26, 2001

[H14.3]. The semantics in SIP are identical to those defined in
[H14.3].

Note: An empty Accept-Encoding

Contact: REGISTER requests MAY contain one or more Contact
header field is permissible,
even though the syntax fields. Contact addresses are presented in [H14.3] does not provide for it.
It is equivalent to Accept-Encoding: identity, i.e., only the identity encoding, meaning no encoding, is permissible.

If no Accept-Encoding
Contact header field is present in fields of REGISTER requests.

Note that user agents MUST NOT send a request, new registration (containing
new Contact header fields, as opposed to a retransmission) until they
have received a response from the
server MUST use registrar for the "identity" encoding.

HTTP/1.1 [H14.3] states that previous one.

The following optional Contact header parameters also contain
behavior specific to the server registration process.

action: The "action" parameter has been deprecated. UACs SHOULD
NOT use the
"identity" encoding unless it has additional information
about "action" parameter.

expires: The "expires" parameter indicates how long the capabilities of UAC
would like the client. This binding to be valid. The parameter is either
a number indicating seconds or a quoted string containing a
SIP-date. If this parameter is needed for
backwards-compatibility with old HTTP clients and does not
affect SIP.

10.8 Accept-Language

The Accept-Language general-header follows the syntax defined in
[H14.4]. The rules for ordering the languages based on provided, the q
parameter apply to SIP as well. When used in SIP, value of
the Accept-Language
general-header Expires header field can be used to allow the client to indicate to determines how long the server in which language it would prefer to receive reason
phrases, session descriptions binding is
valid. Implementations MAY treat values larger than 2**32-1
(4294967295 seconds or status responses carried 136 years) as message
bodies. A proxy MAY use this field equivalent to help select the destination for
the call, for example, 2**32-1.

10.2.1 Adding Bindings with REGISTER

For a human operator conversant in simple registration, a language
spoken by REGISTER request sent to a registrar
includes contact addresses to which requests should be forward for
the caller.

Example:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

10.9 Alert-Info originating user's address of record. The Alert-Info header field indicates that address of record
itself (i.e. 'sip:carol@chicago.com') MUST populate the content indicated in To header of
the URLs should be rendered instead REGISTER. The Contact header fields of ring tone. A user SHOULD be
able to disable this feature selectively to prevent unauthorized
disruptions.

Alert-Info = "Alert-Info" ":" # ( "<" the request typically
contain SIP URIs that identify particular SIP endpoints (i.e.
'sip:carol@cube2214a.chicago.com'), but they MAY use any URI ">" *( ";" generic-param ))

Handley/Schulzrinne/Schooler/Rosenberg [Page 51]

Internet Draft scheme;
this way a SIP July 20, 2001

generic-param = token [ "=" ( token | host | quoted-string ) ]

Example:

Alert-Info: <http://wwww.example.com/sounds/moo.wav>

10.10 Allow

The Allow header field lists UA can choose to register telephone numbers (with the set
tel URL, [13]) or email addresses (with a mailto URL, [18]) as
Contacts for an address of methods supported by record.

For example, if Carol, whose address of record is to register with
the user
agent generating registrar associated with the message. An Allow header field MUST location service of chicago.com.
This location service would then be present
in accessed by a 405 (Method Not Allowed) response to any request, proxy server that
receives requests targeting users in the chicago.com domain, and SHOULD
hence new requests for Carol's address of record will be
present in routed to
her SIP endpoint.

Once a 2xx OPTIONS response. In this usage, client has established bindings at a registrar, it indicates MAY send
subsequent registrations containing new bindings or modifications to
pre-existing bindings as necessary. The 2xx response to the
set REGISTER
message will contain (in Contact header fields) a complete list of methods
bindings that can be invoked on the resource identified by have been registered for this address of record at this
registrar.

Various Authors [Page 41]

Internet Draft SIP October 26, 2001

Figure 2: REGISTER example

Various Authors [Page 42]

Internet Draft SIP October 26, 2001

10.2.1.1 Setting the
Request-URI Expiration Interval of Contact Addresses

When a client sends a REGISTER request, it MAY suggest an expiration
interval that indicates how long the request sent by client would like the UAC.

Allow SHOULD
registration to be present valid (although as is detailed in Section 10.3,
the registrar has the ultimate say).

There are two ways in which a client can suggest an INVITE request (initial expiration
interval for a binding: through an Expires header, or re-INVITE),
and SHOULD be present in any 2xx response to an INVITE. In this
usage, it indicates what methods can "expires"
Contact header parameter. The latter allows expiration intervals to
be invoked within the call leg, suggested on a per-binding basis when more than one binding is
given in a single REGISTER, whereas the user agent sending the message, former suggests an expiration
interval for all Contact header fields that do not contain the duration of the call
leg. For example, if
"expires" parameter.

If neither mechanism for expressing a Allow was suggested expiration time is
present in a 200 OK to an initial
INVITE listing INFO, the caller would know that it REGISTER, a default suggestion of one hour is assumed.

10.2.1.2 Setting Preference among Contact Addresses

If more than one Contact is safe to send an
INFO request on the call leg established by the 200 OK. An Allow MAY
be sent in any 1xx responses for an INVITE; it carries the same
meaning as if it appeared in a 2xx, but conveys this information REGISTER, then the registering
UA intends to associate all of the UAC before URIs given in these Contact
headers with the call is established. address of record present in the To field. This is helpful if list
can be prioritized with the UAC
wishes to send additional requests on the call leg before it is
accepted.

Allow MAY be present in provisional and final responses "q" mechanism.

q: The "q" parameter indicates a relative preference for methods
besides INVITE and OPTIONS. It carries the same semantics in this
case is it does in a 2xx
particular Contact header field compared to OPTIONS.

All methods, including ACK and CANCEL, understood by the UA MUST be
included other bindings
present in this REGISTER message or existing within the list
location service of methods in the Allow header, when present.
The absence registrar. For an example of how a
proxy server uses "q" values, see Section 16.5.

10.2.2 Removing Bindings with REGISTER

Registrations are removed from the registrar through an Allow header MUST NOT expiration
process; registrations are soft state and need to be interpreted refreshed
periodically. A client may attempt to mean that
the UA sending influence the message supports no methods. Rather, it implies
that expiration
intervals selected by the UA is not providing any information on what methods it
supports.

Supplying an Allow header registrar as described in responses to methods other
than OPTIONS cuts down on the number of messages needed.

Handley/Schulzrinne/Schooler/Rosenberg [Page 52]

Internet Draft SIP July 20, 2001

Allow = "Allow" ":" 1#Method

10.11 Authorization Section 10.2.1.

A registering user agent that wishes to authenticate itself with a UAS or
registrar -- usually, but not necessarily, after receiving requests the immediate removal of a 401
response -- MAY do so binding
by including specifying an Authorization header field with
the request. expiration interval of "0" for that contact address
in a REGISTER. It is RECOMMENDED that user agents support this
mechanism so that bindings can be removed (for whatever reason)
before their expiration interval has passed.

The Authorization REGISTER-specific Contact header field value consists of credentials
containing the authentication information of "*" applies to
all registrations, but it MUST only be used when the user agent for the
realm Expires header
is present with a value of the resource being requested.

Section 18.2 overviews the use "0".

Various Authors [Page 43]

Internet Draft SIP October 26, 2001

Use of the Authorization "*" Contact header field, and
Section 19 describes the syntax and semantics when used with HTTP
Basic and Digest authentication.

10.12 Call-ID

The Call-ID general-header field uniquely identifies value allows a particular
invitation or
registering user agent to remove all registrations of a particular client. Note that a
single multimedia conference can give rise to several calls its bindings
expediently.

10.2.3 Fetching Bindings with
different Call-IDs, e.g., if REGISTER

If no Contact headers are present in a user invites REGISTER, then the UA is not
in fact registering any new bindings, and the list of bindings is
therefore left unchanged. As noted above, in a single individual
several times successful response to
this REGISTER message, the same (long-running) conference.

For an INVITE request, complete list of existing bindings is
returned, and thus a callee user agent server SHOULD NOT alert REGISTER without Contact headers serves as a
fetch operation.

10.2.4 Refreshing Registrations

When a 2xx response has been received by the user if client for a REGISTER
request, the user has responded previously to client MUST determine when each of the Call-ID bindings
enumerated in the
INVITE request. If response needs to be refreshed. This may include
bindings that were registered in previous REGISTER transactions.

Since the user is already a member list of bindings returned in the conference and response to a REGISTER may
contain bindings that were not included in this REGISTER transaction,
the conference parameters contained client must correlate Contact header fields in the session description have
not changed, a callee user agent server MAY silently accept response with
the call,
regardless of Contact header fields it sent in the Call-ID. An invitation for an existing Call-ID or
session can change request in order to
establish proper expiration timers. This correlation should be
performed in accordance with the parameters of URI comparison rules given in
Section 21.1.4.

The registering UA MUST re-register each contact address at least as
often as the conference. mandated expiration interval. A client
application MAY decide to simply indicate to the user REGISTER that the
conference parameters refreshes
a binding SHOULD have been changed and accept the invitation
automatically or it MAY require user confirmation.

A user may be invited to the same conference or call using several
different Call-IDs. If desired, Call-ID as the client MAY use identifiers within request which created
the session description to detect this duplication. For example, SDP
contains binding. The CSeq header SHOULD have a session id and version numeric sequence number in the origin (o) field.

The REGISTER and OPTIONS methods use
that is one higher than the Call-ID value (in addition
to sent in the CSeq value) last request with the
same Call-ID.

Note that a UA MUST must update its expiration timers for refreshing
each binding every time it receives a response to unambiguously match requests and responses. All
REGISTER requests issued by a single client registration
request.

Registration refreshes SHOULD use be sent to the same
Call-ID, at least within address as the same boot cycle. For these requests, it
makes no difference whether
original registration, unless redirected.

10.2.5 Discovering a Registrar

Depending on the Call-ID value matches an existing
call or not.

Handley/Schulzrinne/Schooler/Rosenberg [Page 53]

Internet Draft policy of their administrative domain, SIP July 20, 2001

Since the Call-ID is generated by and for SIP, there is no
reason to deal UAs can
be configured with the complexity address of URL-encoding and
case-ignoring string comparison.

callid = token [ "@" token ]
Call-ID = ( "Call-ID" | "i" ) ":" callid

The callid MUST be a globally unique identifier and MUST NOT local registrar. Some UAs may be
reused for later calls. Use of cryptographically random identifiers
[29] is RECOMMENDED. Implementations MAY use the form "localid@host".
Call-IDs are case-sensitive and are simply compared byte-by-byte.

Using cryptographically random identifiers provides some
protection against session hijacking. Call-ID, To and From
are needed to identify a call leg. The distinction between
call and call leg matters in calls
equipped with third-party
control.

For systems which have tight bandwidth constraints, many of protocol tools (outside the
mandatory scope of SIP) that allow
them to discover their local registrar dynamically.

Various Authors [Page 44]

Internet Draft SIP headers have a compact form, October 26, 2001

Note that as discussed in Section
13. These are an alternate names for the headers which occupy less space means of discovering a registrar if no
local registrar is configured in the message. In the case of Call-ID, user agent, clients MAY register
via multicast. Multicast registrations are addressed to the compact form well-
known "all SIP servers" multicast address "sip.mcast.net"
(224.0.1.75). This request MUST be scoped to ensure it is i.

For example, both of not
forwarded beyond the following are valid:

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

10.13 Call-Info

The Call-Info general header field provides additional information
about boundaries of the caller administrative system. This
MAY be done with either TTL or callee, administrative scopes (see [19]),
depending on whether it what is found implemented in a
request or response. The purpose of the URI is described by the
"purpose" parameter. "icon" designates an image suitable as an iconic
representation network. SIP user agents MAY
listen to that address and use it to become aware of the caller or callee; "info" describes location of
other local users (see [20]); however, they do not respond to the caller
or callee
request.

Multicast registration may be inappropriate in general, e.g., through a web page; "card" provides some
environments, for example, if multiple businesses share the
same local area network.

If a
business card (e.g., in vCard [30] or LDIF [31] formats).

Handley/Schulzrinne/Schooler/Rosenberg [Page 54]

Internet Draft SIP July 20, 2001

Call-Info = "Call-Info" ":" # ( "<" URI ">" *( ";" info-param) )
info-param = "purpose" "=" ( "icon" | "info" | "card" | token )
| generic-param

Example:

Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
<http://www.example.com/alice/> ;purpose=info

10.14 Contact

Among the methods discussed in UA knows of an appropriate registrar it SHOULD attempt to
register with this specification, server periodically - management of registration
intervals is detailed below.

10.3 Processing of REGISTER at the Contact
general-header field can appear in INVITE, OPTIONS, ACK, and Registrar

A registrar is a UAS that responds to a REGISTER
requests, and in 1xx, 2xx, 3xx, request, and 485 responses. Other methods
defined elsewhere may allow or require the use of stores
the Contact header
field. This information gathered from that request in a location service that
is generally necessary if the recipient of this method
needs in turn accessible to send proxy servers within its administrative
domain. A registrar handles requests to the originator. In general, it provides as a
URL where the user can be reached for further communications.

In some of the cases below, UAS (in conformity with
Section 8.2 and Section 17.2) but it accepts only the client uses information from REGISTER method
and generates only the
Contact header field responses detailed in Request-URI of future requests. In these
cases, this section. Note that
the client copies all but REGISTER method also does not support the "method-param" Record-Route or Route
header, and "header"
elements of that proxy servers MUST NOT add Record-Route headers to
REGISTER requests.

A registrar must know (through provisioning or some other mechanism)
the addr-spec part of set if administrative domain(s) for which its associated location
service(s) are responsible. REGISTER requests MUST be processed by a
registrar in the Contact header field into order that they are received.

Upon the
Request-URI arrival of a REGISTER message, the request. It uses registrar MUST inspect
the "header" parameters Request-URI to create
headers determine whether it has access to a location
service responsible for the request, replacing any default headers normally used.
Unless the client is configured domain to use which this request is
addressed. If this message is for some other administrative domain,
then if the registrar can act as a default proxy for all
outgoing requests, server, it then directs SHOULD forward
the request to the address and
port specified by the "maddr" and "port" parameters, using addressed domain (following the
transport protocol given general behavior
for proxying messages described in the "transport" parameter. If "maddr" is
a multicast address, the value of "ttl" is used as the time-to-live
value.

INVITE, OPTIONS and ACK requests: INVITE requests MUST, and ACK
requests MAY contain Section 16).

When a single Contact header indicating registrar receives a
single URI from which location the request REGISTER message, it is originating.
The URI SHOULD contain RECOMMENDED that
the address of registrar authenticate the client itself
(i.e., its IP address, or a FQDN user agent client. Mechanisms for the host, or an SRV
record with the highest priority entry beingan FQDN

Various Authors [Page 45]

Internet Draft SIP October 26, 2001

authentication of that
host). See SIP user agents are described in Section 16 20.2;
registration behavior in no way overrides the generic authentication
framework for usage SIP. If no authentication mechanism is available, the
registrar MAY take the From address as the asserted identity of the Contact header for
routing subsequent requests. For OPTIONS, Contact provides
a hint where future SIP requests can be sent or
originator of the request.

Once the identity of the registering user
can be contacted via non-SIP means.

INVITE 1xx responses: A UAS sending a provisional response (1xx)
MAY insert a Contact response header. It has been ascertained, it is
RECOMMENDED that the same

Handley/Schulzrinne/Schooler/Rosenberg [Page 55]

Internet Draft SIP July 20, 2001

semantics in registrar determine if the authenticated user
agent is authorized to request and/or modify registrations for this
address of record. For example, a 1xx response as registrar might consult a 2xx INVITE response.
authorization database (directly or through an appropriate protocol)
that maps credentials or other tokens of identity resulting from
authentication to one or more addresses of record for which this
identity is responsible.

Note that CANCEL requests MUST NOT in architectures that support third-party
registration, one entity may be sent to responsible for updating
the registrations associated with multiple addresses of
record.

When the registrar has determined that address, but
rather follow the same path as client is permitted to
make the original request.

INVITE and OPTIONS 2xx responses: A user agent server sending a
definitive, positive response (2xx) request, the registrar MUST insert a single
Contact response extract the address of record
from the To header field of the REGISTER. Note that the registrar
MUST extract the entire To header field indicating a single SIP URI
under which in order to use it is reachable most directly for future SIP
requests, such as ACK, within the same call leg. The URI
SHOULD contain an
index in the address of location service.

Next, the server itself (i.e., registrar MUST query its
IP address, or a FQDN location service (the repository
of previously registered bindings) for the host, or an SRV record set of bindings associated
with this address of record. If the highest priority entry beingan FQDN address of that host). See
Section 16 record is not valid
for usage of this administrative domain (for example, because the Contact header for routing
subsequent requests.

If a UA supports both UDP and TCP, it SHOULD NOT indicate a
transport parameter in username is
not assigned), then the URI. registration attempt fails (see below). A
full URI comparison (as described in Section 21.1.4) MUST be
performed to determine whether a given binding matches this address
of record.

The registrar now MUST extract all the Contact value SHOULD NOT be cached across calls,
as it may not represent header fields from the most desirable location
for a particular destination address.
REGISTER requests and responses: See Section 7. The message (note that there may be no Contact header value of "*" is only used field).

Each contact address in a REGISTER requests.

3xx and 485 responses: The Contact response-header field can MUST now be
used with a 3xx or 485 (Ambiguous) response codes compared to
indicate one or more alternate addresses all
existing registrations at this location service according to try. It can
appear the
rules in responses to BYE, INVITE and OPTIONS methods. The
Contact header field contains Section 21.1.4. Note that URIs giving the new locations
or user names to try, or may simply specify additional
transport parameters. A 300 (Multiple Choices), 301 (Moved
Permanently), 302 (Moved Temporarily) or 485 (Ambiguous)
response SHOULD contain a Contact field containing other than SIP URIs of
new in
contact addresses to MUST be tried. A 301 or 302 response may also
give the same location and username that was being tried
but specify additional transport parameters such as a
different server or multicast address compared according to try or the standard URI
equivalency rules for the URI schema in question.

If a change of
SIP transport from UDP to TCP or vice versa. The client
copies information from match is found among pre-existing registrations, the Contact header field into registrar
MUST copy all parameters associated with the
Request-URI as described above.

4xx, 5xx and 6xx responses: The current Contact response-header header
field
can be used with a 4xx, 5xx or 6xx response to indicate from the
location where additional information about REGISTER message into the error can
be found.

Handley/Schulzrinne/Schooler/Rosenberg pre-existing binding in its

Various Authors [Page 56] 46]

Internet Draft SIP July 20, October 26, 2001

Note that

location service (overwriting with changed values any existing
parameters as necessary, with the Contact header field MAY exception of "expires"). Expiration
intervals for this contact address MUST also refer to a different
entity than the one originally called. For example, a SIP call
connected to GSTN gateway may need to deliver a special information
announcement such as "The number you have dialed has been changed."

A Contact response header field can contain be reset, based on any suitable URI
indicating where
suggested expiration in the called party REGISTER (remember that this can be reached, not limited to SIP
URLs. For example, it could contain URL's for phones, fax, or irc (if
they were defined) or "0").

If no match is found among the set of pre-existing registrations, the
registrar MUST create a mailto: (RFC 2368, [32]) URL.

The following new binding in its location service between
the address of record and the current Contact header field. All
Contact header field parameters are defined. Additional parameters may copied verbatim into this new
binding (again with the exception of "expires"). An expiration
interval MUST be
defined selected by the registrar, taking into account any
suggested expiration for this contact address in other specifications.

q: The "qvalue" indicates the relative preference among REGISTER.

Allowing the
locations given. "qvalue" values are decimal numbers from 0 registrar to 1, with higher values indicating higher preference. The
default value is 0.5.

action: The "action" parameter is used only when registering
with set the REGISTER request. It indicates whether registration interval
protects it against excessively frequent registration
refreshes while limiting the client
wishes state that it needs to
maintain and decreasing the server proxy likelihood of registrations
going stale.

The expiration interval mandated by the registrar may be either
longer or redirect future requests
intended for shorter than the client. If this parameter is not specified interval suggested by the action taken depends on server configuration. In its
response, sender of the
REGISTER, though the registrar SHOULD indicate abide by the mode used. This
parameter is ignored for other requests.

expires: The "expires" parameter indicates how long registering
client's suggestion.

A server MAY decide to lengthen the URI is
valid. The parameter is either expiration interval if
the refresh rate of a number indicating seconds
or particular client exceeds a quoted string containing
threshold, for example.

After the expiration interval selected by the registrar for a SIP-date. If this parameter
is binding
has passed, if the binding has not provided, been refreshed (increasing the value
expiration interval), the registrar SHOULD silently discard the
binding.

Once all bindings in the location service have been updated to
reflect any changes present to contact addresses in the REGISTER
message, the registrar MUST remove any bindings that expire
immediately.

The REGISTER might have set the expiration interval for
some bindings to "0" to remove them before their expiration
interval passes.

Finally, the registrar must generate a response. If the address of
record given in the Expires To header field
determines how long of the URI REGISTER method is valid. Implementations MAY
treat values larger than 2**32-1 (4294967295 seconds or 136
years) as equivalent to 2**32-1.

Handley/Schulzrinne/Schooler/Rosenberg valid
for its administrative domain, then a 200 response MUST be sent,

Various Authors [Page 57] 47]

Internet Draft SIP July 20, October 26, 2001

Even if the "display-name" is empty, the "name-addr" form

which MUST be
used if the "addr-spec" contains contain a comma, semicolon or question mark.
Note that there may or may not be LWS between the display-name and
the "<".

The complete list (within Contact header field fulfills functionality similar to fields) of
the Location header field currently valid bindings in HTTP. However, the HTTP header
only allows one address, unquoted. Since URIs can contain
commas and semicolons as reserved characters, they can be
mistaken for header or parameter delimiters, respectively.
The current syntax corresponds to that for the To and From
header, which also allows location service associated with
the use address of display names.

Example:

Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1

10.15 Content-Disposition

The Content-Disposition header field describes how the message body
or, record contained in the case To field of multipart messages, a message body part is to the REGISTER
request. This list MAY be
interpreted by empty (in which case the UAC or UAS. The SIP header extends 200 would not
contain any Contact headers).

In a successful response to a REGISTER, wherein the MIME
Content-Type (RFC 1806 [33]).

The value "session" indicates that bindings for this
address of record are enumerated as described above, the body part describes a session, registrar
MUST supply an expiration interval for each contact address in either calls
an "expires" parameter of a Contact header or early (pre-call) media. The value "render"
indicates an Expires header. This
interval specifies the expiration interval that has been mandated by
the body part should be displayed or otherwise
rendered to registrar (taking into account the user. For backward-compatibility, if registering UA's suggestion).

If the Content-
Disposition header is not missing, bodies of Content-Type

Handley/Schulzrinne/Schooler/Rosenberg [Page 58]

Internet Draft SIP July 20, 2001

application/sdp imply registration failed because the disposition "session", while other content
types imply "render".

The disposition type "icon" indicates that address of record contained in
the body part contains an
image suitable as an iconic representation To field of the caller or callee.
The value "alert" indicates that the body part contains information,
such as an audio clip, that should REGISTER is not valid for this domain, then a 404
MUST be rendered instead of ring tone. sent.

11 Querying for Capabilities

The handling parameter, handling-parm, describes how the UAS should
react if it receives SIP method OPTIONS allows a message body whose content type client to query another client or disposition
type it does not understand. If the parameter has the value
"optional",
server as to its capabilities. This allows a client to discover
information about the UAS MUST ignore methods, content types, extensions, codecs etc.
supported without actually "ringing" the message body; if other party. For example,
before a client inserts a Require header field into an INVITE listing
an option that it has the value
"required", is not certain the destination UAS MUST return 415 (Unsupported Media Type). If supports, the
handling parameter is missing,
client can query the value "required" is destination UAS with an OPTIONS to be assumed.

If see if this header field is missing, the MIME type determines the default
content disposition. If there is none, "render" is assumed.

10.16 Content-Encoding

Content-Encoding = ( "Content-Encoding" | "e" ) ":"
1#content-coding

The Content-Encoding entity-header field
option is used as a modifier to the
"media-type". When present, its value indicates what additional
content codings have been applied to the entity-body, and thus what
decoding mechanisms MUST be applied returned in order to obtain the media-type
referenced by the Content-Type a Supported header field. Content-Encoding is
primarily used to allow a body to be compressed without losing the
identity

The target of its underlying media type.

If multiple encodings have been applied to an entity, the content
codings MUST be listed in OPTIONS request is identified by the order in Request-URI,
which they were applied.

All content-coding values are case-insensitive. The Internet Assigned
Numbers Authority (IANA) acts as could identify another User Agent or a registry for content-coding value
tokens. See [H3.5] for SIP Server.
Alternatively, a definition server receiving an OPTIONS request with a Max-
Forwards header value of the syntax for content-coding.

Clients 0 MAY apply content encodings respond to the body in requests. If request regardless of
the
server Request-URI.

This behavior is not capable common with HTTP/1.1.

An OPTIONS request sent as part of decoding the body, or an established dialog does not recognize
have any impact on the dialog.

11.1 Construction of OPTIONS Request

An OPTIONS request is constructed using the content-coding values, it MUST send standard rules for a 415 "Unsupported Media
Type" response, listing acceptable encodings in the Accept-Encoding
header. SIP
request as discussed Section 8.1.1.

A server MAY apply content encodings to the bodies in
responses. The server MUST only use encodings listed in the Accept-
Encoding Contact header field MAY be present in the request.

Handley/Schulzrinne/Schooler/Rosenberg an OPTIONS.

Various Authors [Page 59] 48]

Internet Draft SIP July 20, October 26, 2001

10.17 Content-Language

See [H14.12].

10.18 Content-Length

The Content-Length entity-header field indicates the size of

OPEN ISSUE #197: What is the
message-body, in decimal number semantic of octets, sent to the recipient.

Content-Length = ( "Content-Length" | "l" ) ":" 1*DIGIT

An example is

Content-Length: 3495

Applications SHOULD use this Contact

An Accept header field SHOULD be included to indicate the size type of
message body the
message-body UAC wishes to be transferred, regardless of the media type of receive in the
entity. (The size response.

Example OPTIONS request:

OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=23411513a6
Via: SIP/2.0/UDP 10.1.3.3:5060
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.1.3.3
CSeq: 63104 OPTIONS
Contact: <sip:alice@10.1.3.3>
Accept: application/sdp
Contact-Length: 0

11.2 Processing of the message-body does not include the CRLF
separating headers and body.) Any Content-Length greater than or
equal OPTIONS Request

The response to zero an OPTIONS is constructed using the standard rules
for a valid value. If no body is present SIP response as discussed in a message,
then Section 8.2.7. The response code
chosen is the Content-Length header field MUST same that would have been chosen had the request been
an INVITE. That is, a 200 (OK) would be set returned if the UAS is ready
to zero. If accept a
server receives call, a datagram request without Content-Length, it MUST
assume that 486 (Busy Here) would be returned if the UAS is
busy, etc. This allows an OPTIONS request encompasses to be used to determine the remainder
basic state of the packet. If a
server receives a datagram request with a Content-Length, but the
value differs from UAS, which can be an indication of whether the size UAC
will accept an INVITE request.

Note that this use of OPTIONS has limitations due the body sent differences in the request, the
server SHOULD return
proxy handling of OPTIONS and INVITE requests. While a 400 (Bad Request) response.

If forked INVITE
can result in multiple 200 OK responses being returned, a response does not contain forked
OPTIONS will only result in a Content-Length, the client assumes
that single 200 OK response, since it encompasses the remainder of the datagram packet or the data
until the stream connection is closed, as applicable. Section 12
describes how to determine
treated by proxies using the length of non-INVITE handling. See Section 13.2.1
for the message body.

The ability normative details.

Allow, Accept, Accept-Encoding, Accept-Language, and Supported header
fields SHOULD be present in a 200 OK response to omit Content-Length simplifies the creation
of cgi-like scripts that dynamically generate responses.

10.19 Content-Type

The Content-Type entity-header an OPTIONS request.

A Contact header field indicates the media type of the
message-body sent to the recipient. The "media-type" element is
defined MAY be present in [H3.7]. The Content-Type a 200 OK response.

A Warning header MUST field MAY be present if the present.

A message body is not empty. If MAY be sent, the body is empty, and a Content-Length header type of which is present, it indicates that determined by the body of
Accept header in the specific type has zero

Handley/Schulzrinne/Schooler/Rosenberg OPTIONS request.

Various Authors [Page 60] 49]

Internet Draft SIP July 20, October 26, 2001

length (for example, if it is an emtpy audio file).

Content-Type = ( "Content-Type" | "c" ) ":" media-type

Examples of this header field are

Content-Type: application/sdp
Content-Type: text/html; charset=ISO-8859-4

10.20 CSeq

Clients MUST add the CSeq (command sequence) general-header field

Example OPTIONS response (corresponding to
every request. A CSeq header field in a request contains the request
method and in Section
11.1):

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=23411513a6
Via: SIP/2.0/UDP 10.1.3.3:5060
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.1.3.3
CSeq: 63104 OPTIONS
Contact: <sip:carol@10.3.6.6>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Contact-Length: 274

v=0
o=carol 28908764872 28908764872 IN IP4 10.3.6.6
s=-
t=0 0
c=IN IP4 10.3.6.6
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

12 Dialogs

A key concept for a single decimal sequence number. The sequence number MUST
be expressible as user agent is that of a 32-bit unsigned integer. dialog. A server MUST echo the
CSeq value from the request in its response. The CSeq header serves
to order transactions within dialog
represents a call leg, and to provide peer- to-peer SIP relationship between a means to
uniquely identify transactions.

CSeq = "CSeq" ":" 1*DIGIT Method

For requests two user agents
that are outside of a call leg, or persists for a request that
initiates a session, the value some time. The dialog facilitates sequencing of
messages between the sequence number is arbitrary,
but MUST be less than 2**31. For requests which are subsequent ones
within an existing call leg (such as a re-INVITE or BYE), the CSeq
header MUST contain strictly monotonically increasing user agents, and contiguous
(increasing-by-one) sequence numbers; sequence numbers do not wrap
around. Retransmissions proper routing of the same request carry the same CSeq
value.

For requests outside of
between both them. The dialog represents a call leg, ordering is irrelevant, and so
the value of the CSeq number context in which to
interpret SIP messages. The previous section discussed method
independent UA processing for requests received by and responses outside of a UAS is not
important. For
dialog. This section discusses how those requests within a call leg, ordering is important.
Therefore, a UAS MUST remember the highest sequence number for any
request received within a call leg. The server MUST reject, using and responses are
used to construct a
400 class response, any request dialog, and then how subsequent requests and
responses are sent within a call leg with a lower
sequence number. Any request that is received with a sequence number
higher than the highest received so far (even it is higher by more
than one), SHOULD be accepted.

Handley/Schulzrinne/Schooler/Rosenberg dialog.

Various Authors [Page 61] 50]

Internet Draft SIP July 20, October 26, 2001

If a client initiates a session, and receives multiple 200 class
responses,

A dialog is identified at each establishes UA with a separate call leg. For subsequent
requests within each of those call legs (each of dialog ID, which differs only
by the consists of
a Call-ID value, a local URI and local tag in the To field), (together called the CSeq numbers increment independently
from local
address), and a remote URI and remote tag (together called the other call legs. Furthermore, remote
address). The dialog ID at each UA involved in the CSeq numbering space dialog is
unique in each direction. That is, not the CSeq values in requests from A
to B are independent of
same. Specifically, the values in requests from B local URI and local tag at one UA are
identical to A.

The ACK request MUST contain the same CSeq numeric value as remote URI and remote tag at the
INVITE request peer UA. The tags
are opaque tokens that it refers to, but facilitate the generation of unique dialog
IDs.

A dialog ID is also associated with all responses, and with any
request that contains a Method of "ACK". tag in the To field. The
CANCEL request MUST contain rules for computing
the same CSeq numeric value as dialog ID of a message depend on whether the
request it cancels, but with entity is a Method of "CANCEL".

The Method UAC or
UAS. For a UAC, the Call-ID value allows of the client dialog ID is set to distinguish the response to a
CANCEL request from that
Call-ID of the request it message, the remote address is cancelling. CANCEL
requests can be generated by proxies; if they were set to increase the
sequence number, it might conflict with a later request issued by To field of
the
user agent for message, and the same call.

With a length local address is set to the From field of 32 bits, a server could generate, within a single
call, the
message (these rules apply to both requests and responses). As one request
would expect, for a second for about 136 years before needing to wrap
around. The initial UAS, the Call-ID value of the sequence number dialog ID is chosen so that
subsequent requests within set to
the same call will not wrap around. A
non-zero initial value allows Call-ID of the message, the remote address is set to use a time-based initial sequence
number, if the client desires. From
field of the message, and the local address is set to the To field of
the message.

A client could, dialog contains certain pieces of state needed for example, choose further message
transmissions within the 31 most significant bits dialog. This state consists of the Call-ID,
a 32-bit second clock as an initial local sequence number.

Example:

CSeq: 4711 INVITE

10.21 Date

Date is number (used to order requests from the UA to its
peer), a general-header field. Its syntax is:

Date = "Date" ":" SIP-date
SIP-date = rfc1123-date

See [H14.18] for remote sequence number (used to order requests from its peer
to the UA), and a definition route set, which is an ordered list of rfc1123-date. Note that unlike
HTTP/1.1, SIP only supports the most recent RFC 1123 [34] formatting
for dates. As in [H3.3], SIP restricts the timezone in SIP-date to

Handley/Schulzrinne/Schooler/Rosenberg [Page 62]

Internet Draft SIP July 20, 2001

"GMT", while RFC 1123 allows any timezone. URIs. The consistent use of GMT between Date, Expires and Retry-
After headers allows implementation
route set is the set of simple clients servers that
do not have need to be traversed to send a notion of absolute time. Note that rfc1123-
date
request to the peer. A dialog can also be in the "early" state, which
occurs when it is case-sensitive.

The Date header field reflects created with a provisional response, and then
transition to the time "established" state when the request or final response
is first sent. Thus, retransmissions have the same Date header field
value as comes.

12.1 Creation of a Dialog

Dialogs are created through the original.

Registrars MUST include this header in REGISTER generation of non-failure responses if they use
absolute expiration times
to requests with specific methods. Within this specification, only
the 2xx and SHOULD include it for all responses.

The Date header field can be used 1xx responses to INVITE establish a dialog. A dialog
established by simple end systems
without a battery-backed clock non-final response to acquire a notion of
current time. However, in its GMT-form, it requires clients
to know their offset from GMT.

10.22 Encryption

The Encryption general-header field specifies that the content has
been encrypted. Section 18 describes the overall SIP security
architecture and algorithms. This header field request is intended called an early
dialog. Extensions MAY define other means for end-
to-end encryption of requests and responses. Requests creating dialogs.
Section 13 gives more details that are encrypted
based on the public key belonging specific to the entity named in the To
header field. Responses are encrypted based on the public key
conveyed in INVITE method.
Here, we describe the Response-Key header field. Note process for creation of dialog state that the public keys
themselves may is
not be used for the encryption. This depends dependent on the
particular algorithms used.

For any encrypted message, at least the message body and possibly
other message header fields are encrypted. An application receiving method.

12.1.1 UAS

When a UAS responds to a request or with a response containing an Encryption header field decrypts
the body and then concatenates the plaintext that establishes a
dialog (such as a 2xx to INVITE), the request line and
headers of the original message. Message UAS MUST copy all Record-Route
headers in the decrypted
part completely replace those with from the same field name in request into the
plaintext part. (Note: If only response, and MUST maintain the body
order of those headers. This includes the message is to be
encrypted, the body has to be prefixed with CRLF to allow proper
concatenation.) Note that the request method URIs, URI parameters, and Request-URI cannot
be encrypted.

Encryption only provides privacy; the recipient has no
guarantee that the request or response came from the party
listed in the From message header, only that the sender
used the recipient's public key. However, proxies will not

Handley/Schulzrinne/Schooler/Rosenberg

Various Authors [Page 63] 51]

Internet Draft SIP July 20, October 26, 2001

be able to modify the request or response.

Encryption = "Encryption" ":" encryption-scheme 1*SP
#encryption-params
encryption-scheme = token
encryption-params = generic-param

The token indicates the form of encryption used; it is described in
Section 18.

Since proxies can base their forwarding decision on

any combination
of SIP header fields, there is no guarantee that an encrypted request
"hiding" Record-Route header fields will reach parameters, whether they are known or unknown
to the same destination as an
otherwise identical un-encrypted request.

10.23 Error-Info UAS. The Error-Info response header provides UAS MUST add a pointer Contact header field to additional
information about the error status response. This
The Contact header field is
only contained contains an address where the UAS would like
to be contacted for subsequent requests in 3xx, 4xx, 5xx and 6xx responses.

Error-Info = "Error-Info" ":" # ( "<" URI ">" *( ";" generic-param ))

10.24 Expires

The Expires entity-header field gives the date and time after which dialog (which includes
the message content expires.

This header field is currently defined only ACK for the REGISTER, as
described in Section 7, and INVITE methods.

For INVITE requests, it is a request and response-header field. In a
request, the caller can limit 2xx response in the validity case of an invitation, for
example, if a client wants to limit INVITE). Generally, the time duration
host portion of a search or
a conference invitation. A user interface MAY take this as a hint to
leave the invitation window on the screen even if the user URI is not
currently at the workstation. This also limits the duration IP address of a
search. If the request expires before the search completes, host, or its FQDN.
The URI provided in the proxy
returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily)
response, Contact header MUST be a server can advise SIP URL.

The UAS then constructs the client state of the maximal dialog. This state MUST be
maintained for the duration of the redirection.

Handley/Schulzrinne/Schooler/Rosenberg [Page 64]

Internet Draft SIP July 20, 2001

Note that the expiration time does not affect dialog. First, the duration route set MUST
be computed by following these steps:

1. The list of URIs in the
actual session that may result from Record-Route headers in the invitation. Session
description protocols may offer
request, if present, are taken, including any URI
parameters.

2. The URI in the ability to express time limits on Contact header from the session duration, however. request if present,
is taken, including any URI parameters. The value URI is appended
to the bottom of this field can be either a SIP-date or an integer number the list of seconds (in decimal), measured URIs from the receipt of previous step.

Contact was not mandatory in RFC2543. Thus, if the request.
The latter approach UAS
is preferable for short durations, as it does talking to an older UAC, the UAC might not
depend on clients and servers sharing have
inserted the Contact header.

3. The resulting list of URIs is called the route set

These rules clearly imply that a synchronized clock.
Implementations MAY treat values larger than 2**32-1 (4294967295 or
136 years) as equivalent UA MUST be able to 2**32-1.

Expires = "Expires" ":" ( SIP-date | delta-seconds )

Two examples of its use are

Expires: Thu, 01 Dec 1994 16:00:00 GMT
Expires: 5

10.25 From

Requests parse
and responses MUST contain process Record-Route header fields. This is a From general-header field,
indicating change
from RFC2543, where all record-route and route processing
was optional for user agents.

It is possible for the initiator of route set to be empty. This will occur if
neither Record-Route headers nor a Contact header were present in the
request. (Note that this may The UAS MUST also remember whether the bottom-most entry in
the route set was constructed from a Contact header or not. This is
effectively a boolean value, which we refer to as CONTACT_SET. This
is needed in order for the UA to determine whether the bottom most
value can be
different updated from subsequent requests; if it was constructed
from a Contact, it can be updated.

The remote sequence number sequence number MUST be set to the initiator value
of the sequence number in the Cseq header of the request. The local
sequence number MUST be empty. The call leg. Requests sent by identifier component of the
callee
dialog ID MUST be set to the caller use value of the callee's address Call-ID in the From header
field.) request. The From
local address component of the dialog ID MUST be set to the To field
in the response to the request (which therefore includes the tag),

Various Authors [Page 52]

Internet Draft SIP October 26, 2001

and the remote address component of the dialog ID MUST contain be set to the "tag" parameter. However, a
server
From field in the request. A UAS MUST be prepared to receive a
request without a tag, tag in the From field, in which case the tag is
considered to effectively have a value of zero. null.

This is to maintain backwards compatibility with RFC2543,
which did not mandate From tags. . The server copies

12.1.2 UAC

When a UAC receives a response that establishes a dialog, it
constructs the From header field from state of the
request to dialog. This state MUST be maintained for
the response. The optional "display-name" is meant to duration of the dialog. First, the route set MUST be
rendered computed by a human-user interface. A system SHOULD use
following these steps:

1. The list of URIs present in the display
name "Anonymous" Record-Route headers in the
response are taken, if present, including all URI
parameters, and their order is reversed.

2. The URI in the identity of Contact header from the client response, if
present, is taken, including all URI parameters, and
appended to remain hidden. the end of the list from the previous step.

3. The SIP-URL MUST NOT contain list of URIs resulting from the "transport-param", "maddr-param",
"ttl-param", or "headers" elements. A server that receives a SIP-URL
with these elements ignores them.

Even if above two operations is
referred to as the "display-name" route set

It is empty, possible for the "name-addr" form MUST route set to be
used empty. This will occur if
neither Record-Route headers nor a Contact header were present in the "addr-spec" contains
response. The UAC MUST also remember whether the bottom-most entry in
the route set was constructed from a comma, question mark, Contact header or
semicolon. Syntax issues are discussed in Section 10.5.

Handley/Schulzrinne/Schooler/Rosenberg [Page 65]

Internet Draft SIP July 20, 2001

From = ( "From" | "f" ) ":" ( name-addr | addr-spec )
*( ";" from-param )
from-param = tag-param | generic-param
tag-param = "tag" "=" token

Examples:

From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

The "tag" value MUST be globally unique and cryptographically random
with at least 32 bits of randomness. It SHOULD differ not. This is
effectively a boolean value, which we refer to as CONTACT_SET. This
is needed in order for each call
leg.

For the purpose of identifying call legs, two From or To header
fields are equal UA to determine whether the bottom most
value can be updated from subsequent requests; if and only if:

o it was constructed
from a Contact, it can be updated.

The addr-spec component is equal, according local sequence number sequence number MUST be set to the rules in
Section 2.1.

o Any "tag" and "generic-param" parameters are equal, compared
according to value of
the case-sensitivity rules in Section 10. Only
parameters that appear sequence number in both the Cseq header fields are compared.

Call-ID, To and From are needed to identify a call leg.
The distinction between call and call leg matters in calls
with multiple responses to a forked of the request. The format remote
sequence number MUST be empty (it is
similar to established when the equivalent RFC 822 [26] header, but with UA sends a
URI instead of just an email address.

10.26 In-Reply-To

The In-Reply-To
request header field enumerates within the call-IDs that
this call references or returns.

This allows automatic dialog). The call distribution systems to route
return calls identifier component of the
dialog ID MUST be set to the originator value of the first call and allows
callees to filter calls, so that only calls that return
calls they have originated will be accepted. This field is
not a substitute for request authentication.

Handley/Schulzrinne/Schooler/Rosenberg [Page 66]

Internet Draft SIP July 20, 2001

In-Reply-To = "In-Reply-To" ":" 1# callid

Example:

In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com

10.27 Max-Forwards Call-ID in the request. The Max-Forwards request-header field may
local address component of the dialog ID MUST be used with any SIP method set to limit the number From
field in the request, and the remote address component of proxies or gateways that can forward the
request dialog
ID MUST be set to the next downstream server. This can also be useful when To field of the client is attempting response. A UAC MUST be
prepared to trace receive a request chain which appears to be
failing or looping response without a tag in mid-chain.

Max-Forwards = "Max-Forwards" ":" 1*DIGIT

The Max-Forwards value the To field, in
which case the tag is considered to effectively have a decimal integer indicating the remaining
number value of times this request message null.

This is allowed to be forwarded.

Each proxy or gateway recipient of maintain backwards compatibility with RFC2543,
which did not mandate To tags.

Various Authors [Page 53]

Internet Draft SIP October 26, 2001

12.2 Requests within a request containing Dialog

Once a Max-
Forwards header field MUST check and update its value prior to
forwarding the request. If dialog has been established between two UAs either of them MAY
initiate new transactions as needed within the received value is zero (0), dialog. However, a
dialog imposes some restrictions on the
recipient use of simultaneous
transactions.

A TU MUST NOT forward the request and returns 483 (Too many
hops). Instead, initiate a server MAY act as new regular transaction within a final recipient for OPTIONS
requests. It dialog
while a regular transaction is RECOMMENDED that the server include Supported, Server
and Allow header fields in progress (in either direction)
within that dialog.

OPEN ISSUE #113: Should we relax the response.

If the received Max-Forwards value constraint on non-
overlapping regular transactions?

A refresh request sent within a dialog is greater than zero, then the
forwarded message MUST contain an updated Max-Forwards field with defined as a
value decremented by one (1).

Example:

Max-Forwards: 6

10.28 MIME-Version

See [H19.4.1].

10.29 Organization

Handley/Schulzrinne/Schooler/Rosenberg [Page 67]

Internet Draft SIP July 20, 2001

The Organization general-header field conveys request that
can modify the name route set of the
organization to which dialog. For dialogs that have been
established with an INVITE, the entity issuing only refresh request defined is re-
INVITE (see Section 14). Other extensions may define different
refresh requests for dialogs established in other ways.

Note that an ACK is NOT a refresh request.

12.2.1 UAC Behavior

12.2.1.1 Generating the Request

A request or response
belongs. It MAY also be inserted within a dialog is constructed by proxies at using many of the boundary
components of an
organization.

The field MAY be used by client software to filter calls.

Organization = "Organization" ":" TEXT-UTF8-TRIM

10.30 Priority the state stored as part of the dialog.

The Priority request-header To header field indicates the urgency of the request as perceived by MUST be set to the client.

Priority = "Priority" ":" priority-value
priority-value = "emergency" | "urgent" | "normal"
| "non-urgent" | other-priority
other-priority = token

It is RECOMMENDED that remote address,
and the value of "emergency" only From header field MUST be used when
life, limb or property are in imminent danger.

Examples:

Subject: A tornado is heading our way!
Priority: emergency

Subject: Weekend plans
Priority: non-urgent

These are set to the values of RFC 2076 [35], with local address (both
including tags, assuming the addition of
"emergency".

10.31 Proxy-Authenticate tags are not null).

The Proxy-Authenticate response-header field Call-ID of the request MUST be included as part set to the Call-ID of the dialog.
Requests within a 407 (Proxy Authentication Required) response. It may also occur

Handley/Schulzrinne/Schooler/Rosenberg [Page 68]

Internet Draft SIP July 20, 2001 dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in a 401 (Unauthorized) response each direction. Therefore, if the request was forked. The field local sequence number is not
empty, the value consists of a challenge that indicates the authentication
scheme local sequence number MUST be incremented by
one, and parameters applicable to the proxy for this Request-URI.

Unlike its usage within HTTP, value MUST placed into the Proxy-Authenticate header Cseq header. If the local
sequence number is empty, an initial value MUST be
passed upstream in the response to chosen using the UAC. In SIP, only UAC's can
authenticate themselves to proxies.
guidelines of Section 8.1.1.4. The syntax for this header is defined method field in [H14.33]. See 19 for further
details on its usage.

A client SHOULD cache the credentials used for a particular proxy
server and realm for Cseq header
MUST match the next request to that server. Credentials
are, in general, valid for a specific value method of the Request-URI at request.

With a
particular proxy server. If length of 32 bits, a client contacts could generate, within a proxy server that has
required authentication in the past, but the client does not have
credentials
single call, one request a second for the particular Request-URI, it MAY attempt about 136 years
before needing to use the
most-recently used credential. wrap around. The server responds with 407 if the
client guessed wrong.

This suggested caching behavior initial value of the

Various Authors [Page 54]

Internet Draft SIP October 26, 2001

sequence number is motivated by proxies
restricting phone calls to authenticated users. It seems
likely chosen so that in most cases, all destinations require subsequent requests
within the same password. Note that end-to-end authentication is
likely to be destination-specific.

10.32 Proxy-Authorization

The Proxy-Authorization request-header field call will not wrap around. A non-zero
initial value allows the client to
identify itself (or its user) clients to use a proxy which requires
authentication. time-based initial
sequence number. A client could, for example, choose the 31
most significant bits of a 32-bit second clock as an
initial sequence number.

The Proxy-Authorization field value consists Request-URI of
credentials containing requests is determined according to the authentication information following
rules:

The UAC takes the list of URI in the user
agent for route set inserted into the proxy and/or realm
request URI of the resource being requested.

Unlike Authorization, request, including all URI parameters. Any URI
parameters not allowed in the Proxy-Authorization request URI MUST then be stripped. Each
of the remaining URIs (if any) from the route set , including all URI
parameters, MUST be placed into a Route header field applies
only into the
request, in order.

A TU SHOULD follow the rules just mentioned to build the next Request-URI
of the request, regardless of whether the UA uses an outbound proxy that demanded authentication using
the Proxy- Authenticate field. When multiple proxies are used
server or not. However, in some instances, a
chain, UA may not be willing or
capable of sending the Proxy-Authorization header field is consumed by request to the first
outbound proxy that was expecting top element in the route set is
not capable of DNS, and therefore may not be able to receive credentials. A proxy MAY
relay follow those
procedures. In these cases, the credentials from UA MAY send the client request to a local
outbound server. In this case, it MUST NOT remove the next proxy top Route
header.

In dialogs created by an INVITE, if
that is the mechanism by which UA is the proxies cooperatively authenticate
a given request.

See [H14.34] for a definition of caller,
it sets the syntax, and section 19 for a
discussion of its usage.

10.33 Proxy-Require

Handley/Schulzrinne/Schooler/Rosenberg [Page 69]

Internet Draft SIP July 20, 2001

The Proxy-Require header field is used Request-URI to indicate proxy-sensitive
features that MUST be supported by the proxy. If a proxy server does
not understand the option, same value it MUST respond by returning status code
420 (Bad Extension) used for the
initial request, and list those options sends it to its local outbound server.

Bug#161: Which Request-URI does not understand in the Unsupported header. callee use?

A UAC SHOULD attempt include a Contact header in any refresh requests within
a dialog, and unless there is a need to retry change it, the request,
without using URI SHOULD be
the features listed same as used in previous requests within the Unsupported header.

See dialog. As discussed
in Section 10.35 for more details on the mechanics of this message
and 12.2.2, a usage example.

Proxy-Require = "Proxy-Require" ":" 1#option-tag

10.34 Record-Route

The Record-Route Contact header field has in a refresh request updates the following syntax:

Record-Route = "Record-Route" ":" 1# ( name-addr *( ";" rr-param ))
rr-param = generic-param

Details of
route set. This allows a UA to provide a new contact address, should
its use address change during the duration of the dialog.

However, requests that are described in Section 16.

10.35 Require

The Require general-header field is used by clients to tell user
agent servers about options that not refresh requests do not affect the client expects
route set for the server to
support in order to properly process dialog.

Once the request. If a server does
not understand request has been constructed, the option, it MUST respond by returning status code
420 (Bad Extension) and list those options it does not understand in address of the Unsupported header. A UAC SHOULD attempt to retry server is
computed and the request,
without request is sent, using the features listed in same procedures for
requests outside of a dialog (Section 8.1.1).

12.2.1.2 Processing the Unsupported header.

Require = "Require" ":" 1#option-tag

Example:

C->S: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: com.example.billing
Payment: sheep_skins, conch_shells

S->C: SIP/2.0 420 Bad Extension

Handley/Schulzrinne/Schooler/Rosenberg Responses

Various Authors [Page 70] 55]

Internet Draft SIP July 20, October 26, 2001

Unsupported: com.example.billing

This is to make sure that the client-server interaction

The UAC will proceed without delay when all options are understood
by both sides, and only slow down if options are not
understood (as in receives responses to the example above). For a well-matched
client-server pair, request from the interaction proceeds quickly,
saving transaction
layer.

The behavior of a round-trip often required by negotiation
mechanisms. In addition, it also removes ambiguity when the
client requires features UAC that receives a 3xx response for a request sent
within a dialog is the server does not
understand. Some features, such same as call handling fields,
are only of interest to end systems.

Proxy and redirect servers MUST ignore features that are not
understood. If a particular extension requires that intermediate
devices support it, if the extension MUST be tagged request would have been sent
outside a dialog. This behavior is described in the Proxy-Require
field as well (see Section 10.33).

10.36 Response-Key

The Response-Key request-header field can be used by a client to
request the key 13.2.2.

Note however that when the called user agent SHOULD use to encrypt the
response with. The syntax is:

Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param
key-scheme = token
key-param = generic-param

The "key-scheme" gives UAC tries alternative locations
it still uses the type of encryption to be used route set for the
response. Section 18 describes security schemes.

If the client insists that dialog to build the server return an encrypted response,
it includes a

Require: org.ietf.sip.encrypt-response
Route header field in its of the request.

If the server cannot encrypt a UAC has a route set for
whatever reason, it MUST follow normal Require header field
procedures a dialog, and return receives a 420 (Bad Extension) response. If this Require 2xx response to
a refresh it sent, the Contact header field of the response is
examined. If not present, the route set remains unchanged. If the
response had a server SHOULD still encrypt if it can.

10.37 Retry-After

Handley/Schulzrinne/Schooler/Rosenberg [Page 71]

Internet Draft SIP July 20, 2001

The Retry-After response-header Contact header field, and the boolean variable
CONTACT_SET is false, the URL in the Contact header field can be used with a 503 (Service
Unavailable) in the
response is added to indicate how long the service bottom of the route set , and CONTACT_SET is expected to
be unavailable
set to true. If the requesting client and with refresh request response had a 404 (Not Found),
600 (Busy), or 603 (Decline) Contact header
field, and CONTACT_SET is true, the URL in the Contact header field
of the response to indicate when the called
party anticipates being available again. The refresh request replaces the bottom value of this field can
be either an SIP-date in
the route set is responded with a non-2xx final response the route
set remains unchanged as if no refresh request had been issued.

If the response for the a request within a dialog is a 481
(Call/Transaction Does Not Exist) or an integer number of seconds (in decimal)
after a 408 (Request Timeout) the time of UAC
SHOULD terminate the response.

An optional comment can be used to indicate additional information
about dialog.

For INVITE initiated dialogs terminating the time dialog
consists of callback. An optional "duration" parameter
indicates how long the called party sending a BYE.

12.2.2 UAS behavior

The UAS will be reachable starting at receive the
initial time of availability. request from the transaction layer. If no duration parameter is given, the
service is assumed to be available indefinitely.

Retry-After = "Retry-After" ":" ( SIP-date | delta-seconds )
[ comment ] *( ";" retry-param )
retry-param = "duration" "=" delta-seconds
| generic-param

Examples of its use are

Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in
request has a meeting)
Retry-After: Mon, 01 Jan 9999 00:00:00 GMT
(Dear John: Don't call me back, ever)
Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600
Retry-After: 120

In tag in the third example, To header field, the callee is reachable for one hour starting
at 21:00 GMT. In UAS core computes the last example,
dialog identifier corresponding to the delay request and compares it with
existing dialogs. If there is 2 minutes.

10.38 Route

The Route header field has a match, this is a mid-dialog request.
In that case, the following syntax:

Route = "Route" ":" 1# ( name-addr *( ";" rr-param ))

Details same processing rules for requests outside of its use are described a
dialog, discussed in Section 16.

10.39 Server

The Server response-header field contains information about the

Handley/Schulzrinne/Schooler/Rosenberg [Page 72]

Internet Draft SIP July 20, 2001

software used 8.2, are applied by the user agent server to handle UAS once the request. The
syntax for this field
request is defined received from the transaction layer.

Requests that do not change in [H14.38].

10.40 Subject

This header field provides a summary or indicates any way the nature state of a dialog may be
received within a dialog (e.g., an OPTIONS request). They are
processed as if they had been received outside the
call, allowing call filtering without having to parse the session
description. (Note dialog.

Requests within a dialog MAY contain Record-Route and Contact header
fields. However, requests that the session description does are not have to use refresh requests do not update
the same subject indication as route set for the invitation.)

Subject = ( "Subject" | "s" ) ":" TEXT-UTF8-TRIM

Example:

Subject: Tune in - they dialog. This specification only defines one
refresh request: re-INVITE (see Section 14).

Various Authors [Page 56]

Internet Draft SIP October 26, 2001

Special rules apply when updated Record-Route or Contact header
fields are talking about your work!

10.41 Supported

The Supported general-header field enumerates all received inside a refresh request. If a UAS has a route
set for a dialog, and receives a refresh for that dialog containing
Record-Route header fields, it MUST copy those header fields into any
2xx response to that request. If the capabilities of boolean variable CONTACT_SET is
true, the client or server. This Contact header field SHOULD be included in all
requests (except ACK) and the request (if present) replaces
the last entry in all responses.

Including the route set the UAS MUST add the URL in the
Contact header field in all responses greatly
simplifies the use of extensions for call control in
subsequent transactions with the same server.

Syntax:

Supported = ( "Supported" | "k" ) ":" 1#option-tag

10.42 Timestamp

The Timestamp general-header field describes when re- INVITE to the client sent bottom of the
request route set
, and then set CONTACT_SET to true. If the server. The client uses request did not contain a
Contact header field, the current time value route-set at the
time of transmission, i.e., each retransmission of a request is
likely to have a different timestamp value.

The value of UAS remains unchanged.

If the timestamp remote sequence number is of significance only to the client and empty, it MAY use any timescale. The server MUST echo be set to the exact same value

Handley/Schulzrinne/Schooler/Rosenberg [Page 73]

Internet Draft SIP July 20, 2001
of the sequence number in all provisional and final responses and MAY, if it has accurate
information about this, add a floating point the Cseq header in the request. If the
remote sequence number indicating was not empty, but the sequence number of seconds that have elapsed since it has received the
request. The timestamp
request is used by the client to compute the round-
trip time to lower than the server so that it can adjust remote sequence number, the timeout value for
retransmissions.

Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]

Note that there request is out
of order and MUST NOT be any LWS between rejected with a DIGIT and 500 response. If the decimal
point.

10.43 To

The To general-header field specifies remote
sequence number was not empty, and the "logical" recipient sequence number of the
request.

To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
*( ";" to-param )
to-param = tag-param | generic-param

Requests and responses MUST contain a To general-header field,
indicating request
is greater than the desired recipient of remote sequence number, the request. The optional
"display-name" request is meant in order.
It is possible for the CSeq header to be rendered higher than the remote
sequence number by more than one. This is not an error condition, and
a human-user interface. The UAS or redirect server copies the To header field into its response, SHOULD be prepared to receive and MUST add a "tag" parameter. process requests with CSeq
values more than one higher than the previous received request. The SIP-URL
UAS MUST NOT contain then set the "transport-param", "maddr-param",
"ttl-param", or "headers" elements. A server that receives a SIP-URL
with these elements removes them before further processing.

The "tag" parameter serves as a general mechanism remote sequence number to distinguish
multiple instances of a user identified by a single SIP URL. As
proxies can fork requests, the same request can reach multiple
instances value of a user (mobile and home phones, for example). As each
can respond, there needs to be a means to distinguish the responses
from each at the caller. The situation also arises with multicast
requests. The tag
sequence number in the To Cseq header field serves to distinguish
responses at the UAC. It MUST be placed in the To field request.

12.3 Termination of a Dialog

Dialogs can end in several different ways, depending on the
response by user agent, registrar and redirect servers, but MUST NOT
be inserted into responses forwarded upstream by proxies. However,

Handley/Schulzrinne/Schooler/Rosenberg [Page 74]

Internet Draft SIP July 20, 2001

responses generated locally by method.
When a proxy, and then sent upstream, MUST
contain a tag.

A UAS or redirect server MUST add dialog is established with INVITE, it is terminated with a "tag" parameter for all final
responses for all transactions within
BYE. No other means to terminate a call leg. All such parameters
have the same value within the same call leg. These servers SHOULD
add the tag for informational responses during the initial INVITE
transaction, dialog are described in this
specification, but MUST add extensions can define other ways.

13 Initiating a tag to informational responses for all
subsequent transactions.

See Section 10.25 for details of the "tag" parameter. The "tag"
parameter in To headers is ignored when matching responses Session

13.1 Overview

When a user agent client desires to
requests that did not contain initiate a "tag" in their To header.

Section 15 describes when the "tag" parameter MUST appear in
subsequent requests. Note that if session (for example,
audio, video, or a game), it formulates an INVITE request. The INVITE
request already contained a tag,
this tag MUST be mirrored in the response; asks a new tag MUST NOT be
inserted.

Section 10.25 describes how To and From header fields are compared
for the purpose of matching requests server to call legs. establish a session. This request is
forwarded by proxies, eventually arriving at one or more UAS SHOULD which
can potentially accept requests even if they do not recognize the URI
scheme (e.g., a tel: URI) or if invitation. These UAS's will frequently
need to query the To header does not address user about whether to accept the
user. Only Request-URI that do not match invitation. After
some time, those UAS can accept the recipient should cause
requests to be rejected.

Even if invitation (meaning the "display-name" session
is empty, the "name-addr" form MUST to be
used if established) by sending a 2xx response. If the "addr-spec" contains invitation is
not accepted, a comma, question mark, 3xx,4xx,5xx or
semicolon. Note that LWS 6xx response is common, but not mandatory between sent, depending on the
display-name and
reason for the "<".

The following are examples of valid To headers:

To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
To: sip:+12125551212@server.phone2net.com

Call-ID, To and From are needed to identify a call leg.
The distinction between call and call leg matters in calls
with multiple responses from rejection. Before sending a forked request. The "tag" is
added to the To header field in final response, the UAS
can also send a provisional response (1xx) to allow
forking of future requests for the same call by proxies,
while addressing only one of advise the possibly several
responding user agent servers. It also allows several
instances UAC of
progress in contacting the callee to send requests that can be

Handley/Schulzrinne/Schooler/Rosenberg called user.

Various Authors [Page 75] 57]

Internet Draft SIP July 20, October 26, 2001

distinguished.

10.44 Unsupported

The Unsupported response-header field lists

After possibly receiving one or more provisional responses, the features not
supported by UA
will get one or more 2xx responses or one non-2xx final response.
Because of the server. See Section 10.35 protracted amount of time it can take to receive final
responses to INVITE, the reliability mechanisms for INVITE
transactions differ from those of other requests (like OPTIONS). Once
it receives a usage example and
motivation.

Syntax:

Unsupported = "Unsupported" ":" 1#option-tag

10.45 User-Agent

The User-Agent general-header field contains information about the
client user agent originating final response, the request. UAC needs send an ACK for every
final response it receives. The syntax and semantics
are defined in [H14.43].

10.46 Via

The Via field indicates the path taken by procedure for sending this ACK
depends on the request so far. This
prevents request looping type of response. For final responses between 300 and ensures replies take the same path as
699, the requests, which assists ACK processing is done in firewall traversal and other unusual
routing situations.

10.46.1 Requests

The client originating the request MUST insert into transaction layer, and follows
one set of rules (See Section 17). For 2xx responses, the request a Via
field containing ACK is
generated by the transport protocol used UAC core.

A 2xx response to send the message, an INVITE establishes a session, and it also
creates a dialog between the
client's host name or network address and, if not UA that issued the default port
number, INVITE and the port number at which it wishes to receive responses.
(Note UA
that this port number can differ generated the 2xx response. Therefore, when multiple 2xx
responses are received from different remote UAs (because the UDP source port
number INVITE
forked), each 2xx establishes a different dialog. All these dialogs
are part of the request.) A fully-qualified domain name is RECOMMENDED.
Each subsequent proxy server that sends same call.

This section provides details on the establishment of a session using
INVITE.

13.2 Caller Processing

13.2.1 Creating the Initial INVITE

Since the initial INVITE represents a request onwards MUST add outside of a dialog,
its own additional Via construction follows the procedures of Section 8.1.1. Additional
processing is required for the specific case of INVITE.

An Allow header field before any existing Via fields. A proxy
that receives a redirection (3xx) response and then searches
recursively, MUST use (Section 22.5) SHOULD be present in the same Via headers as
INVITE. It indicates what methods can be invoked within a dialog, on
the original proxied
request.

A client that sends UA sending the INVITE, for the duration of the dialog. For
example, a request to UA capable of receiving INFO requests within a multicast address MUST add dialog [21]
SHOULD include an Allow header listing the
"maddr" parameter to its Via INFO method.

A Supported header field, and field (Section 22.35) SHOULD add be present in the "ttl"
parameter. (In that case,
INVITE. It enumerates all the maddr parameter SHOULD contain extensions understood by the
destination multicast address, although under exceptional
circumstances it UAC.

An Accept (Section 22.1) header field MAY contain a unicast address.) If a server receives
a request be present in the INVITE.
It indicates which contained an "maddr" parameter content-types are acceptable to the UA, in both
the topmost Via
field, response received by it, and in any subsequent requests sent to
it SHOULD send within dialogs established by the response INVITE. The Accept header is
especially useful for indicating support of various session
description formats.

The UA MAY add an Expires header field (Section 22.19) to limit the address listed
validity of the invitation. If the time indicated in the

Handley/Schulzrinne/Schooler/Rosenberg Expires

Various Authors [Page 76] 58]

Internet Draft SIP July 20, October 26, 2001

"maddr" parameter.

Loop detection

header field is described in Section 17.3.1.

10.46.2 Receiver-tagged Via Header Fields

A proxy or UAS receiving reached and no final answer for the INVITE has been
received the UAC core SHOULD generate a CANCEL request SHOULD check for the first Via
original INVITE.

A UAC MAY also find useful to add, among others, Subject (Section
22.34), Organization (Section 22.24) and User-Agent (Section 22.39)
header
field fields. They all contain useful information related to ensure that it contains the sender's correct network
address, as seen from that proxy. If the Via header contains a domain
name or if it contains an IP address that differs from the packet
source address, the proxy or UAS SHOULD
INVITE.

The UAC MAY choose to add a "received" attribute message body to
that Via header field.

A multi-homed host may not be able the INVITE. Section
8.1.1.9 deals with how to insert a network
address into construct the Via header field that can be reached by fields- Content-Type
among others- needed to describe the next hop, message body.

There are special rules for example because if message bodies that contain a session
description - their corresponding Content-Disposition is "session".
SIP uses an offer/answer model where one UA sends a session
description, called the offer, which contains a proposed description
of the networks is
private. session. The address placed into offer indicates the Via header may differ desired communications means
(audio, video, games), parameters of those means (such as codec
types) and addresses for receiving media from the interface actually used, as that interface is
selected only at packet sending time by offerer. The other
UA responds with another session description, called the IP layer.
Similarly, a request traversing a network address
translator (NAT) will also cause answer,
which indicates which communications means are accepted, the sending address
parameters which apply to
differ those means, and addresses for receiving
media from the address seen by answerer. The offer/answer model can be mapped into