WDIFF

draft-ietf-sip-rfc2543bis-02.txt --> draft-ietf-sip-rfc2543bis-03.txt

Internet Engineering Task Force SIP WG
Internet Draft Handley/Schulzrinne/Schooler/Rosenberg
draft-ietf-sip-rfc2543bis-02.txt
draft-ietf-sip-rfc2543bis-03.txt ACIRI/Columbia U./Caltech/dynamicsoft
November 24, 2000
May 29, 2001
Expires: April November 2001

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 and multimedia
distribution. Members in a session can communicate via multicast or
via a mesh of unicast relations, or a combination of these.

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 requests to
the user's current location. Users can register their current
location. SIP is not tied to any particular conference control
protocol. SIP is designed to be independent of the lower-layer
transport protocol and can be extended with additional capabilities.

Handley/Schulzrinne/Schooler/Rosenberg [Page 1]

Internet Draft SIP November 24, 2000 May 29, 2001

1 Introduction

1.1 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 Internet telephony calls. SIP can invite
participants to unicast and multicast sessions; the initiator does
not necessarily have to be a member of the session to which it is
inviting. Media and participants can be added to an existing session.

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

SIP supports five facets of establishing and terminating multimedia
communications:

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 setup: "ringing", establishment of call parameters at both
called and calling party;

Call handling: including transfer and termination of calls.

SIP is designed as part of the overall IETF multimedia data and
control architecture currently incorporating 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 November 24, 2000 May 29, 2001

multimedia sessions via multicast and the session description
protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions.
However, the functionality and operation of SIP does not depend on
any of these protocols.

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

1.2 Terminology

In this document, the key words "MUST", "MUSTNOT", "MUST NOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "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 Overview of SIP Operation

This section explains 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.
SIP is a request-response protocol, with requests sent by clients and
received by servers. A single implementation typically combines both
client and server functionality. SIP requests can be sent using any
reliable or unreliable protocol, including UDP, SCTP and TCP.
Protocol operation is largely independent of the lower-layer
transport protocol.

This specification defines six SIP request methods: INVITE (Section
4.2.1)
5.1) initiates sessions, ACK (Section 4.2.2) 5.1.1) confirms session
establishment, OPTIONS (Section 4.2.3) 8) requests information about
capabilities, BYE (Section 4.2.4) 6) terminates a sessions, CANCEL (Section 4.2.5)
5.2) cancels a pending session and REGISTER (Section
4.2.6) 7) allows a
client to bind a permanent SIP URL to a temporary SIP URL reflecting
the current network location.

SIP requests and responses consists of a request (or status) line, a
number of header lines and a message body (Section 3).

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

User agents send requests either directly to the address indicated in
the SIP URI or to a designated proxy ("outbound proxy"), independent

Handley/Schulzrinne/Schooler/Rosenberg [Page 3]

Internet Draft SIP November 24, 2000 May 29, 2001

of the destination address. The current destination address 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 request URI. A proxy MAY also forward the
request to another designated proxy regardless of the request URI.
For example, a departmental proxy could forward all authorized
requests to a corporate-wide proxy which then forwards it to the
proxy operated by the Internet service provider, which finally routes
the request based on the request URI.

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

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

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

1.4 Definitions

This specification uses a number of terms to refer to the roles
played by participants in SIP communications. The definitions of
client, server and proxy are similar to those used by the Hypertext
Transport Protocol (HTTP) (RFC 2616 [8]). The terms and 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: Also known as a B2BUA, this is a
logical entity that receives an invitation, and acts as a
UAS to process it. In order to determine how the request
should be answered, it acts as a UAC and initiates a call
outwards. A B2BUA appears like a proxy, but differs in that
it maintains complete call state and must remain in a call.
Since it is nothing more than a concatenation of other
logical functions, no explicit definitions are needed for

Handley/Schulzrinne/Schooler/Rosenberg [Page 4]

Internet Draft SIP May 29, 2001

its behavior.

Call: A call consists of all participants in a conference session invited
by a common source. A SIP call is identified by a globally
unique call-id (Section 6.13). Thus, 10.12), and is created when a user
agent sends an INVITE request. This INVITE request may
generate multiple acceptances, each of which are part of
the same call (but different call legs). Furthermore, if a
user is,
for example, is invited to the same multicast session by several
people, each of these invitations will be a unique call. A point-to-point Internet telephony conversation maps
into a single SIP call. In
a multiparty conference unit (MCU) based call-in
conference, each participant uses a separate call to invite
himself to the MCU.

Call leg: A call leg is a pairwise signaling relationship
between two SUP usage agents. A call leg is established
when a call invitation results in a successful response. It
is identified by the combination of the Call-ID header field
field, the local address of the participant, and the addr-spec remote
address of the other participant. For the caller, the local
address is the From field of the INVITE, and tag the remote
address is the To field of the 200 class response. For the
callee, the local address is the To field of the 200 class
response to the INVITE, and the remote address is the From header fields.
field of the INVITE. SIP URIs are compared according to

Handley/Schulzrinne/Schooler/Rosenberg [Page 4]

Internet Draft SIP November 24, 2000
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 in the opposite
direction, i.e., From B and To A.

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

Client: An application program that sends 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 a
common session description. A conference can have zero or
more members and includes the cases of a multicast
conference, a full-mesh conference and a two-party
"telephone call", as well as combinations of these. Any
number of calls can be used to create a conference.

Downstream: Requests sent in the direction from the caller to

Handley/Schulzrinne/Schooler/Rosenberg [Page 5]

Internet Draft SIP May 29, 2001

the callee (i.e., 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 2xx,
3xx, 4xx, 5xx and 6xx responses are final.

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

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

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 the same values for the Call-ID, To, From and
CSeq header fields. In addition, isomorphic requests have
to have the same Request-URI and the same branch parameter
in their 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

Handley/Schulzrinne/Schooler/Rosenberg [Page 5]

Internet Draft SIP November 24, 2000
information include SIP registrars, databases or mobility
registration protocols. Location services are offered by
location servers. Location servers MAY be part of a SIP
server, but the manner in which a SIP server requests
location services is beyond the scope of this document.

Outbound proxy: A proxy that is located near the originator 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
proxy sends these requests, after any local processing, to
the address indicated in the request-URI. Request-URI. (All other proxy
servers are simply referred as proxies, not inbound
proxies.)

Handley/Schulzrinne/Schooler/Rosenberg [Page 6]

Internet Draft SIP May 29, 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 request and then
waiting for the final response before issuing the next
request as in a sequential search , a parallel search
issues requests without waiting for the result of previous
requests.

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

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

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

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

Registrar: A registrar is a server that accepts REGISTER
requests. A registrar is typically co-located with a proxy
or redirect server and MAY make its information available

Handley/Schulzrinne/Schooler/Rosenberg [Page 6]

Internet Draft SIP November 24, 2000
through the location server.

Regular Transaction: A regular transaction is any transaction
with a method other than INVITE, ACK, or CANCEL.

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

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

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

Handley/Schulzrinne/Schooler/Rosenberg [Page 7]

Internet Draft SIP May 29, 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, to 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 the origin field.

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

Spiral: A spiral is a SIP request which is routed to a proxy,
forwarded onwards, and arrives once again at that proxy,
but this time, with a Request-URI that differs from the
previous arrival. A spiral is not 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 at least for the duration of a SIP transaction. Also
known as a transaction stateful proxy. The behavior of a
stateful proxy is further defined in Section 12.3. 17.3. A
stateful proxy is not the same as a call stateful proxy.

Upstream: Responses sent in the direction from the user agent
server to the 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 a client

Handley/Schulzrinne/Schooler/Rosenberg [Page 7]

Internet Draft SIP November 24, 2000

application logical entity
that initiates a SIP request.

User agent server (UAS): A user agent server is transaction with a server
application that contacts request. This role
lasts only for the user when a SIP request is
received and duration of that returns transaction. In other
words, if a response on behalf piece of software initiates a request, it acts
as a UAC for the user.
The response accepts, rejects or redirects the duration of that request. If it receives a
request later on, it takes on the role of a User Agent

Handley/Schulzrinne/Schooler/Rosenberg [Page 8]

Internet Draft SIP May 29, 2001

Server for the processing of that transaction.

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

User agent (UA): An application A logical entity which can act both acts as both a user
agent client and user agent server. server for the duration of a
call.

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

Proxy, redirect, location and registrar servers defined above are
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
returns 1xx status yes yes yes yes
returns 2xx status no yes yes yes
returns 3xx status yes yes yes yes
returns 4xx status yes yes yes yes
returns 5xx status yes yes yes yes
returns 6xx status no yes yes yes
inserts Via header no yes no no
accepts ACK yes yes yes no

Table 1: Properties of 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 8] 9]

Internet Draft SIP November 24, 2000 May 29, 2001

The host part is 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, or can be recorded during previous invitation interactions.
In many cases, a user's SIP URL can be guessed from their email
address.

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

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

1.4.2 Locating a SIP Server

The Request-URI is determined according to the rules in Section 16
and can be derived from either the Route, Contact or To header
fields.

When a client wishes to send a request, the client either sends it to
a locally configured SIP proxy server, the so-called outbound proxy ,
independent of the Request-URI, or sends it to the IP address and
port corresponding to the Request-URI. The outbound proxy can be
configured by any mechanism, including DHCP [11]. [11] and can be specified
either as a set of parameters such as network address or host name,
protocol port and transport protocol, or as a SIP URI.

If the Request-URI is used, the client needs to determine the
protocol, port and IP address of a server to which to send the
request. A client SHOULD follow the steps below to obtain this
information.

Clients MUST re-run the above selection algorithm, re-drawing any
random numbers involved, once per transaction rather than for each step, unless stated otherwise,
request, i.e., requests within the client SHOULD try same transaction MUST be sent to
contact a server at
the port number listed in same network address. Thus, the Request-URI. If no
port number same address is present in used for the Request-URI,
request, any retransmissions, any associated CANCEL requests and ACK
requests for non-2xx responses. However, ACKs for 2xx responses use

Handley/Schulzrinne/Schooler/Rosenberg [Page 10]

Internet Draft SIP May 29, 2001

another iteration of the client uses port 5060.
If selection algorithm. (Indeed, in many cases,
they may have different request URIs.)

A stateless proxy can accomplish this, for example, by using the Request-URI specifies
modulo N of a protocol, hash of the client contacts Call-ID value or some other combination of
transaction-identifying headers as the
server using that protocol. If no protocol is specified, uniform random number
described in the client
tries UDP (if UDP weighting algorithm of RFC 2782. Here, N is supported). If the attempt fails, or if sum
of weights within the
client doesn't support UDP but supports other protocols, it tries
those protocols in some unspecified order. 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

Handley/Schulzrinne/Schooler/Rosenberg [Page 9]

Internet Draft SIP November 24, 2000
programs: For TCP, connect() returns ECONNREFUSED if the client
could not connect to a server at that address. For UDP, the socket
needs to be bound to 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 the client
finds the server is not reachable at a particular address, it SHOULD
behave as if it had received a 400-class error response to that
request.

The client tries to find one or more addresses for the SIP server 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 SIP server at any of those addresses responds, then the client
concludes the server is down and does not continue on to the next
step.

The service identifier for DNS SRV records [12]

If the client is "_sip".

1. configured with the address of an outbound proxy,
the parameters of the outbound proxy, including transport protocol
and port, become the destination used below.

If there is no outbound proxy, the maddr parameter exists, it becomes destination is the Request-URI.
The destination address used below; is the maddr parameter if not, it exists and the
host element in the
Request-URI if not. The transport protocol is the destination address.

2. transport
parameter.

The service identifier for DNS SRV records [12] is "_sip".

1. If the destination address is an a numeric IP address, the
client contacts the server at the given address and the
port number specified in the Request-URI or the default port and
ignores SIP-URI or, if not specified,
the remaining steps.

3. The Request-URI default port (5060).

If the destination specifies a protocol, the client
contacts the server using that protocol. If no protocol is examined.
specified, the client first tries UDP. If attempt fails, or
if the client does not support UDP but supports other

Handley/Schulzrinne/Schooler/Rosenberg [Page 11]

Internet Draft SIP May 29, 2001

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

The client then skips the remaining steps.

2. If the destination specifies no port number or port number
5060, the transport parameter is inspected:

1. protocol determines the use of one of
the following three rules:

- If the Request-URI destination does not specify a transport protocol,
DNS SRV records are retrieved according to RFC 2782 [12].
The results of the query or queries are merged and
ordered based on priority, keeping only records with
transport protocols that the client supports. Then, the
searching technique outlined in RFC 2782 [12] is used to
select servers in order. Server selection across requests
is independent of previous choices, except as noted below 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 of the servers can be contacted, the client gives
up. If there are no SRV records (with any transport
protocol), DNS address records are used, as described
below.

- If the Request-URI specifies a transport protocol is specified and
the transport this protocol is
supported by the client, the

Handley/Schulzrinne/Schooler/Rosenberg [Page 10]

Internet Draft SIP November 24, 2000 procedure in the paragraph
above is used, limited to DNS resource records with the
transport protocol specified in the Request-URI. SIP-URI.

- If the Request-URI specifies a transport protocol that specified is not supported by
the client, the client gives up.

If there are no SRV records, the Request-URI contains next step applies.

3. If the destination specifies a port number other than 5060
or if there are no SRV records, the client queries the DNS
server for address records for the destination address.
Address records include A RR's, AAAA RR's, or other similar
records, chosen according to the client's network protocol
capabilities.

If the DNS server returns no address records, the client
gives up.

Within a transaction, a stateless proxy MUST always select the same
destination within the set of hosts with If there are address records, the same priority. This can
be accomplished, for example, by using the modulo N of a hash of the
Call-ID value or some other combination of transaction-identifying
headers as the uniform random number described in the weighting
algorithm of RFC 2782. Here, N is the sum of weights within the
priority class.

There are no mandatory rules on how to select a host name for a SIP
server. Users are encouraged to name their SIP servers using the
sip.domainname (e.g., sip.example.com ) convention, as specified
in
RFC 2219 [13]. Users may only know an email address instead of a full
SIP URL for a callee, however. In that case, implementations may be
able to increase the likelihood of reaching a SIP server for that
domain by constructing a SIP URL from that email address by prefixing
the domain name with "sip.". In the future, this mechanism is likely
to become unnecessary as SRV records, described above, become widely
available.

A client MAY step 2 apply.

Clients MUST NOT cache the list of DNS query results if one of the
addresses was contacted successfully. Request for the same
transaction SHOULD be sent to the same network address. Other
requests from the same client select a server from the list of
addresses cached, using the SRV load-balancing mechanism if
applicable. The client must invalidate this list and retry the DNS
query except according to the rules in RFC1035 [14].

A client MAY omit attempting to reach a server which it had failed to
reach for a previous request.

Handley/Schulzrinne/Schooler/Rosenberg [Page 12]

Internet Draft SIP May 29, 2001

RFC 1035 [13].

The results of the DNS lookup operation do not, in general, lead to a
modification of the Request-URI.

Handley/Schulzrinne/Schooler/Rosenberg [Page 11]

Internet Draft SIP November 24, 2000

A proxy is free to modify the Request-URI to any value
desired, but the DNS lookups are usually based on the
Request-URI obtained from a location server.

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

1.4.3 SIP Transaction

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

If a reliable stream protocol is used, request and responses within a
single SIP transaction are carried over the same connection (see
Section 10). 14). Several SIP requests from the same client to the same
server MAY use the same connection or MAY use a new connection for
each request.

If a client sends the request via a unicast datagram protocol such as
UDP, the receiving user agent directs the response according to the
information contained in the Via header fields (Section 6.47). 10.46). Each
proxy server in the forward path of the request forwards the response
using these Via header fields, as described in detail in Sections
6.47.3
10.46.3 and 6.47.4. 10.46.4. For datagram protocols, reliability is achieved
using retransmission (Section 10). 14).

1.4.4 Initiating a Session

A session is initiated with the INVITE request. A successful SIP
invitation consists of two requests, INVITE followed by ACK. The
INVITE (Section 4.2.1) 5.1) request asks the callee to join a particular
conference or establish a two-party conversation. After the callee
has agreed to participate in the call, the caller confirms that it

Handley/Schulzrinne/Schooler/Rosenberg [Page 13]

Internet Draft SIP May 29, 2001

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

The INVITE request typically contains a session description, for
example written in SDP (RFC 2327 [6]) format, that provides the
called party with enough information to join the session. For

Handley/Schulzrinne/Schooler/Rosenberg [Page 12]

Internet Draft SIP November 24, 2000
multicast sessions, the session description enumerates the media
types and formats that are allowed to be distributed to that session.
For a unicast session, the session description enumerates the media
types and formats that the caller is willing to use and where it
wishes the media data to be sent. In either case, if the callee
wishes to accept the call, it responds to the invitation by returning
a similar description listing the media it wishes to use. For a
multicast session, the callee SHOULD only return a session
description if it is unable to receive the media indicated in the
caller's description or wants to receive data via unicast.

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

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

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

1.4.5 Locating a User

A callee may move between a number of different end systems over
time. These locations can be dynamically registered with the SIP
server (Sections 1.4.7, 4.2.6). A location server MAY also use one or
more other protocols, such as finger (RFC 1288 [15]), rwhois (RFC
2167 [16]), LDAP (RFC 1777 [17]), multicast-based protocols [18] or

Handley/Schulzrinne/Schooler/Rosenberg [Page 13] 14]

Internet Draft SIP November 24, 2000 May 29, 2001

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

^
| non-SIP protocols
|

Figure 1: Example of SIP proxy server

operating-system dependent mechanisms to actively determine the end
system where

A callee may move between a user might number of different end systems over
time. These locations can be reachable. A location server MAY dynamically registered with the SIP
server (Sections 1.4.7, 7). A location server MAY also use one or
more other protocols, such as finger (RFC 1288 [14]), rwhois (RFC
2167 [15]), LDAP (RFC 1777 [16]), multicast-based protocols [17] or
operating-system dependent mechanisms to actively determine the end
system where a user might be reachable. A location server MAY return
several locations because the user is logged in at several hosts
simultaneously or because the location server has (temporarily)
inaccurate information. The SIP server combines the results to yield
a list of a zero or more locations.

The action taken on receiving a list of locations varies with the
type of SIP server. A SIP redirect server returns the list to the
client as Contact headers (Section 6.15). A SIP proxy server can
sequentially or in parallel try the addresses until the call is
successful (2xx response) or the callee has declined the call (6xx

Handley/Schulzrinne/Schooler/Rosenberg [Page 14] 15]

Internet Draft SIP November 24, 2000 May 29, 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 of SIP redirect server

Handley/Schulzrinne/Schooler/Rosenberg [Page 15] 16]

Internet Draft SIP November 24, 2000 May 29, 2001

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

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

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

1.4.6 Changing an Existing Session

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

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

1.4.7 Registration Services

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

1.5 Protocol Properties

1.5.1 Minimal State

Handley/Schulzrinne/Schooler/Rosenberg [Page 17]

Internet Draft SIP May 29, 2001

A single conference session or call involves one or more SIP
request-response transactions. Proxy servers do not have to keep
state for a particular call, however, they MAY maintain state for a
single SIP transaction, as discussed in Section 12. 17. For efficiency, a

Handley/Schulzrinne/Schooler/Rosenberg [Page 16]

Internet Draft SIP November 24, 2000
server MAY cache the results of location service requests.

1.5.2 Lower-Layer-Protocol Neutral

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

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

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

For concreteness, this document will only refer to Internet
protocols. However, SIP MAY also be used directly with protocols
such as ATM AAL5, IPX, frame relay or X.25. The necessary naming
conventions are beyond the scope of this document. User agents SHOULD
implement both UDP and TCP transport. Proxy, registrar, and redirect
servers MUST implement both UDP and TCP transport.

1.5.3 Text-Based

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

2 SIP Uniform Resource Locators

SIP URLs are used within SIP messages to indicate the originator
(From), current destination (Request-URI) and final recipient (To) of
a SIP request, and to specify redirection addresses (Contact). A SIP
URL can also be embedded in web pages or other hyperlinks to indicate
that a particular user or service can be called via SIP. When used as

Handley/Schulzrinne/Schooler/Rosenberg [Page 18]

Internet Draft SIP May 29, 2001

a hyperlink, the SIP URL indicates the use of the INVITE method.

The SIP URL scheme is defined to allow setting SIP request-header
fields and the SIP message-body.

Handley/Schulzrinne/Schooler/Rosenberg [Page 17]

Internet Draft SIP November 24, 2000

This corresponds to the use of mailto: URLs. It makes it
possible, for example, to specify the subject, urgency or
media types of calls initiated through a web page or as
part of an email message.

A SIP URL follows the guidelines of RFC 2396 [9] and has the syntax
shown in Fig. 3. The syntax is described using Augmented Backus-Naur
Form (see Section C). Note that Although the ABNF described in Section C uses
implicit whitespace, unescaped whitespace MUST NOT be present within
a SIP URL. Any reserved characters have to be escaped and that the
"set of characters reserved within any given URI component is defined
by that component. In general, a character is reserved if the
semantics of the URI changes if the character is replaced with its
escaped US-ASCII encoding" [9]. Excluded US-ASCII characters [9],
such as space and control characters and characters used as URL
delimiters, also MUST be escaped. URLs MUSTNOT MUST NOT contain unescaped
space and control characters.

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

The components of the SIP URI have the following meanings.

user: The name of the user addressed. Note that this field MAY
be empty where the destination host does not have a notion
of users, e.g., for embedded devices.

telephone-subscriber: If the host is an Internet telephony
gateway, a telephone-subscriber field MAY be used instead
of a user field. The telephone-subscriber field uses the
notation of RFC 2806 [19]. [18]. Any characters of the un-escaped
"telephone-subscriber" that are not either in the set
"unreserved" or "user-unreserved" MUST be escaped. The set
of characters not reserved in the RFC 2806 description of
telephone-subscriber contains a number 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) and the "unwise" characters,
i.e., punctuation of %5b and above.

The telephone number is a special case of a user name and
cannot be distinguished by a BNF. Thus, a URL parameter,
user, is added to distinguish telephone numbers from user
names.

The user parameter value "phone" indicates that the user
part contains a telephone number. Even without this
parameter, recipients of SIP URLs MAY interpret the pre-@
part as a telephone number if local restrictions on the

Handley/Schulzrinne/Schooler/Rosenberg [Page 18] 19]

Internet Draft SIP November 24, 2000 May 29, 2001

SIP-URL = "sip:" [ userinfo "@" ] hostport
url-parameters [ headers ]
userinfo = [ user | telephone-subscriber ] [ ":" password ]
user = *( unreserved | escaped
| "&" | "=" | "+" | "$" | "," | ";" | "?" | "/" )
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*digit "." 1*3DIGIT 1*digit "." 1*3DIGIT 1*digit "." 1*3DIGIT
IPv6reference = "[" IPv6address "]"
IPv6address = hexpart [ ":" IPv4address ]
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEX 1*digit
port = 1*DIGIT *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
ttl-param = "ttl=" ttl
ttl = 1*3DIGIT ; 0 to 255
maddr-param = "maddr=" host
user-param = "user=" ( "phone" | "ip" | other-user )
other-user = token
method-param = "method=" Method
other-param = pname [ "=" pvalue ]
pname = 1*paramchar
pvalue
tag-param = 1*paramchar
paramchar "tag=" UUID
UUID = param-reserved | unreserved 1*( hex | escaped
param-reserved "-" )
other-param = "[" | "]" | "/" | "?" | ":" | "&" ( token | "+" ( token "=" ( token | "$" quoted-string )))
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*( hnv-unreserved | unreserved | escaped ) 1*uric
hvalue = *( hnv-unreserved *uric
uric = reserved | unreserved | escaped )
hnv-unreserved
reserved = "[" | "]" ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
digits = 1*DIGIT

Figure 3: SIP URL syntax

cannot be distinguished by a BNF. Thus, a URL parameter,
user, is added to distinguish telephone numbers from user
names.

The user parameter value "phone" indicates that the user
part contains a telephone number. Even without this
parameter, recipients of SIP URLs MAY interpret the pre-@

Handley/Schulzrinne/Schooler/Rosenberg [Page 20]

Internet Draft SIP May 29, 2001

part as a telephone number if local restrictions on the
name space for user name allow it.

password: The SIP scheme MAY use the format "user:password" in
Handley/Schulzrinne/Schooler/Rosenberg [Page 19]

Internet Draft SIP November 24, 2000
the userinfo field. The use 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 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 not present, the
procedures outlined in Section 1.4.2 are used to determine
the port number to send a request to.

URL parameters: SIP URLs can define specific parameters of the
request. URL parameters are added after the host component
and 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 are defined for UDP
[20],
[19], TCP [21], [20], TLS [22], [21], 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 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 is used.

The ttl parameter determines the time-to-live value of the
UDP multicast packet and MUST only be used if maddr is a
multicast address and the transport protocol is UDP. The
user parameter was described above. For example, to specify
to call j.doe@big.com using multicast to 239.255.255.1 with
a ttl of 15, the following URL would be used:

Handley/Schulzrinne/Schooler/Rosenberg [Page 21]

Internet Draft SIP May 29, 2001

sip:j.doe@big.com;maddr=239.255.255.1;ttl=15

The transport, maddr, and ttl parameters MUSTNOT MUST NOT be used
in

Handley/Schulzrinne/Schooler/Rosenberg [Page 20]

Internet Draft SIP November 24, 2000 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 with the "?"
mechanism within a SIP URL. The special hname "body"
indicates that the associated hvalue is the message-body of
the SIP INVITE request. Headers MUSTNOT MUST NOT be used in the
From and To header fields and the Request-URI; they are
ignored if present. hname and hvalue are encodings of a
SIP header name and value, respectively. All URL reserved
characters in the header names and values MUST be escaped.

Method: The method of the SIP request can be specified with the
method parameter. This parameter MUSTNOT MUST NOT be used in the
From and To header fields and the Request-URI; they are
ignored if present.

Table 2 summarizes where the components of the SIP URL can be used.
Entries marked "m" are mandatory, those marked "o" are optional, and
those marked "-" are not allowed. For optional elements, the second
column indicates the default value if the element is not present.

default Req.-URI To From

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
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
sip:alice@registrar.com;method=REGISTER

Handley/Schulzrinne/Schooler/Rosenberg [Page 22]

Internet Draft SIP May 29, 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 o
headers -- - - - o - o

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

Examples of SIP URLs are:

Handley/Schulzrinne/Schooler/Rosenberg [Page 21]

Internet Draft SIP November 24, 2000

2.1 SIP URL Comparison

SIP URLs are compared for equality according to the following rules:

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

o The ordering of parameters and headers is not significant in
comparing SIP URLs.

o user or telephone-subscriber, password, host, port and any
url-parameter parameters of the URI must match. If a component
is omitted, it matches based on its default value. (For
example, otherwise equivalent URLs without a port
specification and with port 5060 match.) Components not found
in both URLs being compared compared, for which there is no default
value, are ignored.

o Characters other than those in the "reserved" and "unsafe"
sets (see RFC 2396 [9]) are equivalent to their ""%" HEX HEX"
encoding.

o An IP address that is the result of a DNS lookup 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 in both URLs.

Thus, the following URLs are equivalent:

sip:juser@
sip:juser@ExAmPlE.CoM;Transport=udp

while

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

Handley/Schulzrinne/Schooler/Rosenberg [Page 22] 23]

Internet Draft SIP November 24, 2000 May 29, 2001

sip:juser@
sip:juser@ExAmPlE.CoM;Transport=udp

while

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

are not.

Header fields such as Contact, From and To are equal if and only if
their URIs match under the rules above and if their header parameters
(such as contact-param, from-param and to-param) match in name and
parameter value, where parameter names and token parameter values are
compared ignoring case and quoted-string parameter values are case-
sensitive.

2.2 Non-SIP URLs

SIP header fields and the Request-URI MAY contain non-SIP URLs, with
the exceptions noted below. As an example, if a call from a telephone
is relayed to the Internet via SIP, the SIP From header field might
contain a tel: URL [19]. [18].

In the following locations, only SIP URLs are allowed:

o Request-URI in a REGISTER request;

o Contact header field in INVITE, OPTIONS and BYE and 2xx
responses. responses
to INVITE and OPTIONS.

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

3 SIP Message Overview

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

CR and LF instead of CRLF is for backwards-compatibility;
their use is deprecated.

Handley/Schulzrinne/Schooler/Rosenberg [Page 24]

Internet Draft SIP May 29, 2001

Except for the above difference in character sets and line
termination, much of the message syntax is and header fields are
identical to HTTP/1.1; rather than repeating the syntax and semantics
here we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1
specification (RFC 2616 [8]). In addition, we describe SIP in both
prose and an augmented Backus-Naur form (ABNF). See section C for an
overview of ABNF.

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

Handley/Schulzrinne/Schooler/Rosenberg [Page 23]

Internet Draft SIP November 24, 2000

Unlike HTTP, SIP MAY use UDP or other unreliable datagram protocols.
Each such datagram carries one request or response. Datagrams,
including all headers, SHOULDNOT SHOULD NOT be larger than the path maximum
transmission unit (MTU) if the MTU is known, or 1500 bytes if the MTU
is unknown. However, implementations MUST be able to handle messages
up to the maximum datagram packet size. For UDP, this size is 65,535
bytes, including headers.

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

A SIP message is either a request from a client to a server, or a
response from a server to a client.

SIP-message = Request | Response

Both Request (section 4) and Response (section 5) 9) messages use the
generic-message format of RFC 822 [26] [25] for transferring entities (the
body of the message). Both types of messages consist of a start-line,
one or more header fields (also known as "headers"), an empty line
(i.e., a line with nothing preceding the carriage-return line-feed
(CRLF)) indicating the end of the header fields, and an optional
message-body. To avoid confusion with similar-named headers in HTTP,
we refer to the headers describing the message body as entity
headers. These components are described in detail in the upcoming
sections.

Handley/Schulzrinne/Schooler/Rosenberg [Page 25]

Internet Draft SIP May 29, 2001

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

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

Handley/Schulzrinne/Schooler/Rosenberg [Page 24]

Internet Draft SIP November 24, 2000 9.1

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

In the interest of 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.

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 8 12

4.1 Request-Line

The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence. No LWS is allowed in any of the
elements. The Request-URI MUSTNOT MUST NOT be enclosed in "<>". absoluteURI
is defined in [H3.2.1].

Request-Line = Method SP Request-URI SP SIP-Version CRLF

Handley/Schulzrinne/Schooler/Rosenberg [Page 26]

Internet Draft SIP May 29, 2001

Request-URI = SIP-URL | absoluteURI
SIP-Version = "SIP/2.0"

4.2 Methods

The methods are defined below. described 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 and CANCEL
CANCEL, whether the method is defined in this specification or
elsewhere, in the same way, by forwarding
them accordingly. way. Thus, no method-specific support is
required in these servers for methods other than INVITE and CANCEL.
Methods that are not supported by a user agent server or registrar
cause a 501

Handley/Schulzrinne/Schooler/Rosenberg [Page 25]

Internet Draft SIP November 24, 2000 (Not Implemented) response to be returned (Section 7). 11).
As in HTTP, the Method token is case-sensitive.

4.2.1 INVITE

4.3 Request-URI

The INVITE method indicates that the user or service Request-URI is being invited
to participate a SIP URL as described in Section 2 or a session. The message body MAY general
URI (RFC 2396 [9]). In particular, it MUST NOT contain a
description of unescaped
spaces or control characters. It indicates the session user or service to
which the callee this request is being invited. For
two-party calls, addressed. Unlike the caller indicates To field, the type of media it is able to
receive and possibly
Request-URI MAY be re-written by proxies.

As shown in Table 2, the media it is willing to send Request-URI MAY contain the user-param
parameter as well as their
parameters such as network destination. transport-related parameters. A success response MUST
indicate in its message body which media the callee wishes to receive
and MAY indicate the media the callee is going to send.

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

The caller MAY choose 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 server that the caller does not know its
desired media characteristics until the call has been accepted. In
this case, the UAS SHOULD still return
receives a session description in its
informational (1xx) or success (2xx) response, containing those media
streams and codecs it supports.

If the INVITE request did not contain SIP-URL with illegal elements removes them before further
processing.

Transport-related parameters are needed when a complete session description,
the caller MUST include one in the ACK request. A UAC MUSTNOT send an
updated session description in an ACK request if it had already sent proxies
all requests to a complete session description in default proxy, which would then need this
information to generate the INVITE appropriate request. If

Typically, the UAC
wishes to modify sets the session after the call setup has begun, it MUST
use another INVITE request instead.

Delaying the session description until the ACK request is
useful for gateways from H.323v1 to SIP, where the H.323
media characteristics are not known until the call is
established.

A server MAY automatically respond to an invitation for a conference
the user is already participating in, identified either by Request-URI and To to the same
SIP URL, presumed to remain unchanged over long time

Handley/Schulzrinne/Schooler/Rosenberg [Page 26] 27]

Internet Draft SIP November 24, 2000 May 29, 2001

Table 3: SIP headers

Handley/Schulzrinne/Schooler/Rosenberg [Page 27] 28]

Internet Draft SIP November 24, 2000

The behavior of UAS depend on whether they are Internet telephony
gateways May 29, 2001

response to the PSTN. A UAS not acting as a gateway which receives an
INVITE with a previous request, the To would still contain
the long-term, "public" address, while the Request-URI that does not correspond
would be set to one of its
configured addresses, MUST respond with 404 (Not Found).

A UAS acting as a gateway translates the INVITE cached address.

Proxy and redirect servers MAY use the information in the Request-URI
and request into a
telephony signaling message. If header fields to handle the INVITE has a Call-ID value that
matches request and possibly rewrite
the Request-URI. For example, a recent call, request addressed to the UAS compares generic
address sip:sales@acme.com is proxied to the Request-URI 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 of the Request-URI typically agrees with one of the previous INVITE request for
host names of the same Call-ID. receiving server. If it does not, the Request-URI contains additional digits in the "user" part, the
UAS treats server SHOULD
proxy the INVITE as adding additional digits request to the original
dialed string. This address indicated or return a 404 (Not
Found) response if it is known as overlap dialing.

If unwilling or unable to do so. For example,
the gateway knows that Request-URI and server host name can disagree in the telephone number is incomplete, it
returns a 484 (Address Incomplete) status response.

If case of a user agent receives an INVITE request for an existing call leg
firewall proxy that handles outgoing calls. This mode of operation is
similar to that of HTTP proxies.

SIP servers MAY support Request-URIs with a higher CSeq sequence number schemes other than any previous INVITE "sip",
for example the
same Call-ID, it MUST check any version identifiers in the session
description or, if there are no version identifiers, the content of
the session description to see if it has changed. "tel" URI scheme [18]. It MUST also
inspect MAY translate non-SIP URIs
using any mechanism at its disposal, resulting in either a SIP URI or
some other header fields for changes. scheme.

If there is a change,
the user agent MUST update any internal state or information
generated as SIP server receives a result of that header. If request with a URI indicating a scheme the session description has
changed,
server does not understand, the user agent server MUST adjust the session parameters
accordingly, possibly after asking return a 400 (Bad
Request) response. It MUST do this even if the user To header field
contains a scheme it does understand, since proxies are responsible
for confirmation.
(Versioning of processing the session description can be used Request-URI. (The To field is only of interest to accommodate
the
capabilities of new arrivals to a conference, add or delete media or
change from a unicast to a multicast conference.)

If an INVITE UAS.)

4.3.1 SIP Version

Both request for an existing session fails, the session
description agreed upon in and response messages include the last successful INVITE transaction
remains version of SIP in force.

A UAC MUSTNOT issue another INVITE request for the same call leg
before the previous transaction has completed. A UAS that receives an
INVITE before it sent the final response to an INVITE with a lower
CSeq number MUST return a 400 (Bad Request) response use,
and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced
by SIP/2.0) regarding version ordering, compliance requirements, and
upgrading of version numbers. To be compliant with this
specification, applications sending SIP messages MUST include a Retry-After header field with a randomly chosen value SIP-
Version of between 0
and 10 seconds.

If a UA A sends an INVITE request to B and receives an INVITE request
from B before it has received "SIP/2.0". The string is case-insensitive, but
implementations MUST use upper-case.

Unlike HTTP/1.1, SIP treats the response to its request from B, A
MAY return a 500 (Internal Server Error), which SHOULD include version number as a
Retry-After header field specifying when the request literal
string. In practice, this should be
resubmitted. make no difference.

4.4 Option Tags

Option tags are unique identifiers used to designate new options in

Handley/Schulzrinne/Schooler/Rosenberg [Page 28] 29]

Internet Draft SIP November 24, 2000

In most cases, a UA can assume that May 29, 2001

SIP. These tags 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 order definition of messages
received corresponds to the order they were sent. In rare
circumstances, token. The creator of a new SIP
option MUST either prefix the response from B and option with their reverse domain name
or register the request from B
may be reordered on new option with the wire.

In addition, if A or B change multicast addresses, strict transaction
ordering Internet Assigned Numbers
Authority (IANA).

An example of a reverse-domain-name option is necessary so "com.foo.mynewfeature",
whose inventor can be reached at "foo.com". For these features,
individual organizations are responsible for ensuring that both sides agree on option
names do not collide within the final result.

A UAC same domain. The host name part of
the option MUST be prepared to receive media data according to use lower-case; the session
description as soon as it sends an INVITE (or re-INVITE) option name is case-sensitive.

Options registered with IANA do not contain periods and can
start sending media data when it receives a provisional or final
response containing are globally
unique. IANA option tags are case-sensitive.

4.4.1 Registering New Option Tags with IANA

When registering a session description.

The initial INVITE from the UAC SHOULD contain new SIP option, the Allow following information MUST be
provided:

o Name and
Supported description of option. The name MAY be of any length,
but SHOULD 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, and MAY contain the Accept header field. A
200 (OK) response to the initial INVITE for a call SHOULD contain the
Allow and Supported header fields, and MAY contain the Accept header
field.

Including these parameter
fields or parameter values defined by this option. A SIP
option MUST NOT redefine header fields allows the UAC or parameters defined
in either RFC 2543, any standards-track extensions to determine
the features and RFC
2543, or other extensions supported by registered through IANA.

o Indication of who has change control over the UAS option (for
example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of
companies);

o A reference to a further description, if available, for the
duration
example (in order of the call, without probing.

This method MUST be supported by preference) an RFC, a published paper, a
patent filing, a technical report, documented source code or a
computer manual;

Handley/Schulzrinne/Schooler/Rosenberg [Page 30]

Internet Draft SIP proxy, redirect May 29, 2001

o Contact information (postal and user agent
servers as well as clients.

4.2.2 email address).

Registrations should be sent to iana@iana.org

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

5 INVITE, ACK and CANCEL

5.1 INVITE

The ACK request confirms INVITE method indicates that the client has received a final
response to an INVITE request. (ACK is used only with INVITE
requests.) 2xx responses are acknowledged by client user agents, all
other final responses by the first proxy or client user agent to
receive the response. The Via service is always initialized being invited
to participate in a session. The message body MAY contain a
description of the host that
originates session to which the ACK request, i.e., callee is being invited. For
two-party calls, the client user agent after a 2xx
response or caller indicates the first proxy type of media it is able to
receive a non-2xx final response. The
ACK request and possibly the media it is forwarded willing to send as the corresponding INVITE request, based
on well as their
parameters such as network destination. A success response MUST
indicate in its Request-URI and thus MAY take a different path than message body which media the
original INVITE request, callee wishes to receive
and MAY even cause a new transport
connection indicate the media the callee is going to be opened in order send.

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

The ACK caller MAY choose to omit the request does body (i.e., not generate responses for any transport
protocol.

The ACK request MAY contain send a
session description) or send a message body with the final session description to be used by the callee. If that does not list
any media types. This indicates that the ACK message body is
empty, caller does not know its
desired media characteristics until the callee uses call has been accepted. In
this case, the UAS SHOULD still return a session description in its
informational (1xx) or success (2xx) response, containing those media
streams and codecs it supports.

If the INVITE request.
See Section 4.2.1 for further details on the relationship between

Handley/Schulzrinne/Schooler/Rosenberg [Page 29]

Internet Draft SIP November 24, 2000 request did not contain a complete session descriptions description,
the caller MUST include one in INVITE and the ACK requests. request. A proxy server receiving UAC MUST NOT send
an updated session description in an ACK request after having if it had already
sent a 3xx, 4xx,
5xx, or 6xx 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 session description in the To field. INVITE request. If the tag in the ACK To header field matches the tag in the To header
field of UAC wishes
to modify the response, and session after the From, CSeq and Call-ID header fields
in call setup has begun, it MUST
initiate another INVITE transaction after the response match those in current one has
completed.

Delaying the ACK, session description until the ACK request is meant
useful for gateways from H.323v1 to SIP, where the
proxy server. Otherwise, H.323
media characteristics are not known until the ACK SHOULD be proxied downstream as any
other request.

It call is possible
established.

A server MAY automatically respond to an invitation for a conference

Handley/Schulzrinne/Schooler/Rosenberg [Page 31]

Internet Draft SIP May 29, 2001

the user agent client is already participating in, identified either by the SIP
Call-ID or proxy server to
receive multiple 3xx, 4xx, 5xx, and 6xx responses to a
request along a single branch. This can happen under
various error conditions, typically when globally unique identifier within the session
description, with a forking proxy
transitions from stateful to stateless before receiving all
responses. 200 (OK) response.

The various responses will all be identical,
except for the tag in behavior of UAS depend on whether they are Internet telephony
gateways to the To field, which is different for
each one. It can therefore be used PSTN. A UAS not acting as a means to
disambiguate them.

This method MUST be supported by SIP user agents.

4.2.3 OPTIONS

The server is being queried as gateway which receives an
INVITE with a Request-URI that does not correspond to one of its capabilities.
configured addresses, MUST respond with 404 (Not Found).

A server that
believes it can contact the user, such UAS acting as a user agent where gateway translates the user
is logged in and has been recently active, MAY respond to this INVITE request with into a capability set. A called user agent MAY return
telephony signaling message. If the INVITE has a
status reflecting how it would have responded to an invitation, e.g.,
600 (Busy). A server SHOULD return Allow, Accept, Accept-Encoding,
Accept-Language and Supported header fields. The response MAY contain Call-ID value that
matches a message body indicating recent call, the capabilities of UAS compares the end system (rather
than properties of any existing call).

The use Request-URI with the
Request-URI of the Call-ID header field is discussed in Section 6.13. An
OPTIONS requests previous INVITE request for an existing call-id has no impact on that call.

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

4.2.4 BYE

The user agent client uses BYE to indicate the same Call-ID. If
the Request-URI contains additional digits in the "user" part, the
UAS treats the INVITE as adding additional digits to the server original
dialed string. This is known as overlap dialing.

If the gateway knows that it
wishes to release the call. A BYE request telephone number is forwarded like incomplete, it
returns a 484 (Address Incomplete) status response.

If a user agent receives an INVITE request and MAY be issued by either caller or callee. A party to a for an existing call SHOULD issue a BYE request before releasing a call ("hanging

Handley/Schulzrinne/Schooler/Rosenberg [Page 30]

Internet Draft SIP November 24, 2000

up"). A party receiving leg
with a BYE request higher CSeq sequence number than any previous INVITE for the
same Call-ID, it MUST cease transmitting media
streams specifically directed at check any version identifiers in the party issuing session
description or, if there are no version identifiers, the BYE request.

A BYE request from either called or calling party terminates any
pending INVITE at a UA, but content of
the INVITE request transaction session description to see if it has changed. It MUST be
completed with a final response and ACK. also
inspect any other header fields for changes. If the INVITE request contained there is a Contact header, change,
the callee SHOULD
send user agent MUST update any internal state or information
generated as a BYE request to result of that address rather than header. If the session description has
changed, the From address.

This method SHOULD be supported by user agent servers.

4.2.5 CANCEL

The CANCEL request cancels a pending request with server MUST adjust the same Call-ID,
To, From and CSeq (sequence number only) header field values, but
does not affect a completed request or existing calls. (A request is
considered completed if session parameters
accordingly, possibly after asking the server has returned a final status
response.) The UAC user for confirmation.
(Versioning of the session description can use a BYE request be used to terminate a call if accommodate the
CANCEL arrived too late.

A user agent client
capabilities of new arrivals to a conference, add or proxy client MAY issue delete media or
change from a CANCEL request at any
time. A proxy client generates unicast to a CANCEL multicast conference.)

If an INVITE request for branches without
a final response after it has forked a request and receives a 2xx or
6xx response from one of an existing session fails, the branches. A UAC or proxy client also
sends a CANCEL if session
description agreed upon in the time noted last successful INVITE transaction
remains in force.

A UAC MUST NOT issue another INVITE request for the Expires header of same call leg
before the request previous INVITE transaction has elapsed or no provisional or final response was received after a
client-determined timeout interval. Finally, internal logic such as
scripts, can trigger CANCEL requests. completed. A proxy UAS that
receives a CANCEL request forwards an INVITE before it sent the request final response to all
destinations an INVITE
with pending requests.

The Call-ID, To, the numeric part of a lower CSeq number on the same call leg MUST return a 400 (Bad
Request) response and From MUST include a Retry-After header fields in
the CANCEL request are identical to those in the original request.
This allows field with a CANCEL
randomly chosen value of between 0 and 10 seconds.

If a UA A sends an INVITE request to be matched with the B and receives an INVITE request
from B before it
cancels. However, to allow has received the client to distinguish responses response to the
CANCEL its request from those to the original request, the CSeq Method component
is set to CANCEL. The Via B, A
MAY return a 500 (Internal Server Error), which SHOULD include a

Handley/Schulzrinne/Schooler/Rosenberg [Page 32]

Internet Draft SIP May 29, 2001

Retry-After header field is initialized to the proxy
issuing specifying when the CANCEL request. (Thus, responses to this CANCEL request
only reach should be
resubmitted.

In most cases, a UA can assume that the issuing proxy.)

The behavior order of messages
received corresponds to the user agent or redirect server on receiving a
CANCEL request depends on whether order they were sent. In rare
circumstances, the server has already sent a final response for the original request. If it has, from B and the CANCEL request has
no effect from B
may be reordered on the original request, any call state and wire.

In addition, if A or B change multicast addresses, strict transaction
ordering is necessary so that both sides agree on the
responses generated for the original request. If the server has not
issued a final response for the original request, it immediately

Handley/Schulzrinne/Schooler/Rosenberg [Page 31]

Internet Draft SIP November 24, 2000

sends a 487 (Request Terminated) for the original request. For INVITE
requests, the result.

A UAC MUST be prepared to receive media data according to the session
description as usual soon as it sends an ACK request to confirm receipt of
any final response. The CANCEL request itself is answered with INVITE (or re-INVITE) and can
start sending media data when it receives a 200
(OK) response in either case.

A proxy client provisional or UAC cannot rely on receiving a 487 (Request
Terminated) response, as a RFC 2543-compliant UAS will not generate
such a response. If there has been no final
response after 32
seconds, containing a session description.

The initial INVITE from the client UAC SHOULD contain the Allow and
Supported header fields, and MAY consider contain the original transaction to have
been cancelled.

The BYE request cannot be used Accept header field. A
200 (OK) response to cancel branches of the initial INVITE for a
parallel search, since several branches may, through
intermediate proxies, find call SHOULD contain the same user agent server
Allow and
then terminate Supported header fields, and MAY contain the call. To terminate a call instead of
just pending searches, Accept header
field.

Including these header fields allows the UAC must use BYE instead of or
in addition to CANCEL. While CANCEL can terminate any
pending request other than ACK or CANCEL, it is typically
useful only for INVITE. 200 responses to INVITE determine
the features and 200
responses to CANCEL can be distinguished extensions supported by the method in UAS for the Cseq header field.
duration of the call, without probing.

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

5.1.1 ACK

The ACK request confirms that the client has received a final
response to an INVITE request. (ACK is used only with INVITE
requests.) Treatment of ACK for a 200 class response differs
significantly from that of a non-200 class response. 2xx responses
are acknowledged by client user agents, all other SIP server types.

4.2.6 REGISTER

A final responses by
the first stateful proxy or client uses user agent to receive the REGISTER method
response. The Via is always initialized to bind the address listed in host that originates
the
To header field with a SIP server to one or more URIs where ACK request, i.e., the client can be reached, contained in user agent after a 2xx response or
the Contact header fields. These
URIs may use any URI scheme, not limited to SIP.

It is particularly important that REGISTER requests are authenticated
since they allow to redirect future requests (see Section 13.2).

4.2.6.1 Where to Register

A user agent SHOULD attempt to register periodically according first proxy or UAC to receive a non-2xx final response. For a
non-200 class response, the
rules below. A UA is said to be "visiting" if its From address
domain differs from Via in the current network domain and ACK that is said to constructed MUST
be "at
home" if the two are same as the same.

Local server: If an outbound proxy is configured, request being acknowledged. The ACK for a 200
class response will contain Route headers if Record-Route headers
were present in the UA SHOULD
send response. An ACK for a REGISTER non-200 class response
never contains Route headers. The ACK request to it. If the UA for a 200 class
response is visiting, it
uses the From address consisting of the URL-escaped user
identity at the visited domain, e.g., the user identified
as alice@wonderland.com would register forwarded as the corresponding INVITE request, based on

Handley/Schulzrinne/Schooler/Rosenberg [Page 32] 33]

Internet Draft SIP November 24, 2000

alice%40wonderland.com@example.com if she is visiting the
example.com domain.

Multicast: If no local outbound proxy is configured, multicast
registrations are addressed to the well-known "all SIP
servers" multicast address "sip.mcast.net" (224.0.1.75).
This request SHOULD be scoped to ensure it is not forwarded
beyond the boundaries of the administrative system. This
MAY be done with either TTL May 29, 2001

its Request-URI or administrative scopes [27],
depending on what is implemented in Route headers, and thus MAY take a different path
than the network. SIP user
agents original INVITE request, and MAY listen even cause a new transport
connection to that address and use it be opened in order to become
aware of send it. The Request-URI for the location of other local users [18]; however,
they do not respond
ACK is set to the request.

Multicast registration may be inappropriate top entry in some
environments, the route set for example, if multiple businesses
share a 200 class response
(see Section 16). For a non-200 class response, the Request-URI MUST
be the same local area network.

Home server: If as the UA is visiting, it SHOULD also send Request-URI in the request being acknowledged.

The ACK request does not generate responses for any transport
protocol.

The ACK request for a
registration to its home SIP server, identified by its home
address. For example, alice@wonderland.com would send 200 class response MAY contain a
registration message body
with the final session description to be used by the SIP server callee. See
Section 5.1 for further details on the domain
wonderland.com when she is visiting another network. TBD:
What Contact should be used? relationship between session
descriptions in INVITE and ACK requests.

A proxy server receiving an ACK request after having sent a 3xx, 4xx,
5xx, or 6xx response must make a determination about whether the ACK
is for it, or for some user agent SHOULD register with a local or proxy server on startup and
periodically thereafter by sending a REGISTER request. The period further downstream.
This determination is
given made by examining the expiration time indicated tag in the registration response.
It is RECOMMENDED that To field. If
the UA registers via multicast and send a
registration to its "home" address, i.e., tag in the server for ACK To header field matches the domain
that it uses as its From address tag in outgoing requests.

4.2.6.2 REGISTER Header Fields

Request-URI: The Request-URI names the destination To header
field of the
registration request, i.e., the domain of response, and the registrar.
The user name MUST be empty. Generally, From, CSeq and Call-ID header fields
in the domains response match those in the
Request-URI and ACK, the To header field have ACK is meant for the same value;
however, it
proxy server. Otherwise, the ACK SHOULD be proxied downstream as any
other request. However, an ACK not destined for the proxy SHOULD NOT
be retransmitted.

It is possible for a user agent client or proxy server to
receive multiple 3xx, 4xx, 5xx, and 6xx responses to register as a "visitor", while
maintaining one's name. For example,
request along a traveler
sip:alice@acme.com (To) might register single branch. This can happen under
various error conditions, typically when a forking proxy
transitions from stateful to stateless before receiving all
responses. The various responses will all be identical,
except for the Request-
URI sip:atlanta.hiayh.org , with tag in the former To field, which is different for
each one. It can therefore be used as a means to
disambiguate them.

This method MUST be supported by SIP user agents.

5.2 CANCEL

The CANCEL request cancels a pending request with the To same Call-ID,
To, From, top Via header field and the latter as the Request-URI. The
REGISTER Request-URI and CSeq (sequence number
only) header field values, but does not affect a completed request
or existing calls. (A request is no longer forwarded once it has reached considered completed if the server whose authoritative domain is the one listed in
has returned a final status response.) The UAC can use a BYE request
to terminate a call if the Request-URI. CANCEL arrived too late.

Handley/Schulzrinne/Schooler/Rosenberg [Page 33] 34]

Internet Draft SIP November 24, 2000

Call-ID: All registrations from May 29, 2001

A user agent client or proxy client MAY issue a CANCEL request at any
time. A proxy client SHOULD use generates a CANCEL request for branches without
a final response after it has forked a request and receives a 2xx or
6xx response from one of the same
Call-ID header value, at least within branches. A UAC or proxy client also
sends a CANCEL if the same reboot
cycle.

Cseq: Registrations with time noted in the same Call-ID MUST have increasing
CSeq Expires header values. However, of the server does not reject
out-of-order request
has elapsed or no provisional or final response was received after a
client-determined timeout interval. Finally, internal logic such as
scripts, can trigger CANCEL requests.

4.2.6.3 Registering Contact Locations

A stateful proxy that receives a CANCEL request immediately responds
with a 200 class response. It then generates a new registration (as opposed CANCEL, and
forwards the request to all destinations with pending requests. A
stateless proxy, or a retransmission)
until they have received the response from the server stateful proxy with no transaction state for
the
previous one.

Clients may register from different locations, by necessity
using different Call-ID values. Thus, cancelled request, proxies the CSeq value cannot
be used CANCEL request to enforce ordering. Since registrations are
additive, ordering is less the same set of a problem than if each
REGISTER request completely replaced all earlier ones.

We define "address-of-record" as
destinations the SIP address that the registry
knows original request was proxied to.

The Request-URI, topmost Via, Call-ID, To, the registrand, typically numeric part of CSeq
and From header fields in the form "user@domain" rather than
"user@host". In third-party registration, CANCEL request are identical to those
in the entity issuing original request being cancelled, including tags. This allows
a CANCEL request to be matched with the request is different it cancels. However,
to allow the client to distinguish responses to the CANCEL from those
to the entity being registered.

To: The To header field contains original request, the address-of-record whose
registration CSeq Method component is set to be created or updated.

From: CANCEL.
The From Via header field contains the address-of-record of is initialized to the person responsible for proxy issuing the registration. For first-
party registration, it is identical CANCEL
request. (Thus, responses to this CANCEL request only reach the To header field
value.

Contact:
issuing proxy.)

The behavior of the user agent or redirect server on receiving a
CANCEL request MAY contain depends on whether the server has already sent a Contact header field. Future
non-REGISTER requests final
response for the URI given in original request. If it has, the To header
field SHOULD be directed to CANCEL request has
no effect on the address(es) given in original request, any call state and on the
Contact header.
responses generated for the original request. If the request does server has not contain
issued a Contact header, final response for the
registration remains unchanged.

This is useful original request, it immediately
responds to obtain the current list original request with a 487 (Request Terminated),
following normal rules for response retransmissions defined in
Section 14. For INVITE requests, the UAC as usual sends an ACK
request to confirm receipt of
registrations any final response. The CANCEL request
itself is answered with a 200 (OK) response in either case. If the
UAS or redirect server has no record of the request being cancelled,
the CANCEL is responded to with a 481.

A proxy client or UAC cannot rely on receiving a 487 (Request
Terminated) response, as described below.

If a SIP URI in RFC 2543-compliant UAS will not generate
such a registration Contact header field differs
from existing registrations according to response. If there has been no final response after 32
seconds, the rules in client MAY consider the original transaction to have
been cancelled.

The BYE request cannot be used to cancel branches of a

Handley/Schulzrinne/Schooler/Rosenberg [Page 34] 35]

Internet Draft SIP November 24, 2000

Section 2.1, it is added to May 29, 2001

parallel search, since several branches may, through
intermediate proxies, find the list same user agent server and
then terminate the call. To terminate a call instead of registration. If
just pending searches, the UAC must use BYE instead of or
in addition to CANCEL. While CANCEL can terminate any
pending request other than ACK or CANCEL, it is equivalent, according typically
useful only for INVITE. 200 responses to these rules, INVITE and 200
responses to an existing
registration, all Contact CANCEL can be distinguished by the method in
the Cseq header field parameters for this
entry are updated accordingly. URIs field.

This method MUST be supported by proxy servers and SHOULD be
supported by all other than SIP URIs are
compared according server types.

6 BYE

The user agent client uses BYE to indicate to the standard URI equivalency rules
for server that it
wishes to release the URI schema.

All current registrations MUST share the same action value.
Registrations that have a different action than current
registrations for the same user MUST be rejected with
status of 409 (Conflict). call leg. A proxy server ignores the q parameter when processing
non-REGISTER requests, while a redirect server simply
returns that parameter in its Contact response header
field.

Having the proxy server interpret the q parameter BYE request is
not sufficient forwarded like an
INVITE request and MAY be issued by either caller or callee. A BYE
request SHOULD NOT be sent to guide proxy behavior, as it is terminate a pending call request which
has not
clear, for example, how long it is supposed to wait
between trying addresses.

If the registration is changed while generated either a user agent final response or proxy server
processes an invitation, the new information a provisional response
containing a To tag. A party to a call SHOULD be used.

This allows issue a service known as "directed pick-up". In the
telephone network, directed pickup permits BYE request
before releasing a user call ("hanging up"). A party receiving a BYE
request MUST cease transmitting media streams specifically directed
at the party issuing the BYE request.

A UAS receiving a
remote station who hears his own phone ringing BYE request MUST respond to pick up
at any pending requests
received for that station, dial an access code, and call, including INVITE. It is RECOMMENDED that a
487 response is generated.

This method SHOULD be connected to
the calling supported by user as if he had answered his own phone.

4.2.6.4 Registration Expiration

An optional "expires" Contact parameter indicates agent servers.

7 Registrars, Registrations and the desired
expiration time of REGISTER Method

A client uses the registration. If a Contact entry does not have
an "expires" parameter, REGISTER method to bind the Expires address listed in the
To header field is used as the
default value. If neither of these mechanisms is used, with a SIP URIs are
assumed server to expire after one hour. Other URI schemes have no
expiration times. Registrations not refreshed after this amount of
time SHOULD or more URIs where the
client can be silently discarded. A registrar SHOULDNOT use a longer
lifetime than reached, contained in the one requested, but MAY Contact header fields. These
URIs may use a shorter one.

Registration refreshes any URI scheme, not limited to SIP.

It is particularly important that REGISTER requests are authenticated
since they allow to redirect future requests (see Section 18.2).

7.1 Where to Register

A user agent SHOULD be sent attempt to register periodically according to the same
rules below. A UA is said to be "visiting" if its From address as domain
differs from the
original registration, unless redirected.

4.2.6.5 List of Current Registrations current network domain and is said to be "at home"
if the two are the same.

Handley/Schulzrinne/Schooler/Rosenberg [Page 35] 36]

Internet Draft SIP November 24, 2000

2xx REGISTER responses May 29, 2001

Local server: If an outbound proxy is configured, the UA SHOULD list all current registration in
send a REGISTER request to it. If the
Contact header field. An "expires" parameter MUST indicate UA is visiting, it
uses the
expiration time From address consisting of the registration.

4.2.6.6 Removing Registrations

Registrations expire as described above or may be removed explicitly
by setting URL-escaped user
identity at the expires parameter for an existing registration to zero
or including an Expires: 0 header field. Registrations are matched
based on visited domain, e.g., the user, host, port and maddr parameters. A client can
remove all user identified
as alice@wonderland.com would register as
alice%40wonderland.com@example.com if she is visiting the
example.com domain.

Multicast: If no local outbound proxy is configured, multicast
registrations by including a single Contact header field
with are addressed to the wildcard well-known "all SIP
servers" multicast address "*".

Support of this method is RECOMMENDED; registrars "sip.mcast.net" (224.0.1.75).
This request MUST support it.

4.3 Request-URI

The Request-URI is a SIP URL as described in Section 2 or a general
URI (RFC 2396 [9]). In particular, it MUSTNOT contain unescaped
spaces or control characters. It indicates the user or service be scoped to
which this request ensure it is being addressed. Unlike not forwarded
beyond the To field, boundaries of the
Request-URI administrative system. This
MAY be re-written by proxies.

As shown done with either TTL or administrative scopes [27],
depending on what is implemented in Table 2, the Request-URI network. SIP user
agents MAY contain the user-param
parameter as well as transport-related parameters. A server listen to that
receives a SIP-URL with illegal elements removes them before further
processing.

Transport-related parameters are needed when a UAC proxies
all requests address and use it to a default proxy, which would then need this
information become
aware of the location of other local users [17]; however,
they do not respond to generate the appropriate request.

Typically,

Multicast registration may be inappropriate in some
environments, for example, if multiple businesses
share the UAC sets same local area network.

Home server: If the Request-URI and To UA is visiting, it SHOULD also send a
registration to the same its home SIP URL, presumed to remain unchanged over long time
periods. However, if the UAC has cached server, identified by its home
address. For example, alice@wonderland.com would send a more direct path
registration to the callee, e.g., from SIP server for the domain
wonderland.com when she is visiting another network. TBD:
What Contact header field of should be used?

A user agent SHOULD register with a
response to local server on startup and
periodically thereafter by sending a previous request, REGISTER request. The period is
given by the To would still contain expiration time indicated in the long-term, "public" registration response.
It is RECOMMENDED that the UA registers via multicast and send a
registration to its "home" address, while i.e., the server for the domain
that it uses as its From address in outgoing requests.

7.2 REGISTER Header Fields

Request-URI: The Request-URI
would be set to names the cached address.

Proxy and redirect servers MAY use destination of the information
registration request, i.e., the domain of the registrar.
The user name MUST be empty. Generally, the domains in the
Request-URI and request header fields to handle the request and possibly rewrite To header field have the Request-URI. same value;
however, it is possible to register as a "visitor", while
maintaining one's name. For example, a request addressed to the generic
address sip:sales@acme.com is proxied to traveler
sip:alice@acme.com (To) might register under the particular person, e.g.,
sip:bob@ny.acme.com Request-
URI sip:atlanta.hiayh.org , with the To field remaining as
sip:sales@acme.com. At ny.acme.com , Bob then designates Alice former as the To

Handley/Schulzrinne/Schooler/Rosenberg [Page 36] 37]

Internet Draft SIP November 24, 2000

the temporary substitute.

The host part of May 29, 2001

header field and the Request-URI typically agrees with one of latter as the
host names of the receiving server. If Request-URI. The
REGISTER request is no longer forwarded once it does not, has reached
the server SHOULD
proxy the request to the address indicated or return a 404 (Not
Found) response if it whose authoritative domain is unwilling or unable to do so. For example, the Request-URI and server host name can disagree one listed in
the case of Request-URI.

Call-ID: All registrations from a
firewall proxy that handles outgoing calls. This mode of operation is
similar to that of HTTP proxies.

SIP servers MAY support Request-URIs with schemes other than "sip",
for example client SHOULD use the "tel" URI scheme [19]. It MAY translate non-SIP URIs
using any mechanism same
Call-ID header value, at its disposal, resulting in either a SIP URI or
some other scheme.

If a SIP server receives a request least within the same reboot
cycle.

Cseq: Registrations with a URI indicating a scheme the same Call-ID MUST have increasing
CSeq header values. However, the server does not understand, reject
out-of-order requests.

7.3 Registering Contact Locations

REGISTER requests are processed in the order received. Clients SHOULD
avoid sending a new registration (as opposed to a retransmission)
until they have received the response from the server MUST return 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 400 (Bad
Request) response. It MUST do this even problem than if each
REGISTER request completely replaced all earlier ones.

We define "address-of-record" as the SIP address that the registry
knows the registrand, typically 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: The To header field contains a scheme it does understand, since proxies are the address-of-record whose
registration is to be created or updated.

From: The From header field contains the address-of-record of
the person responsible for processing the Request-URI. (The registration. For first-
party registration, it is identical to the To header field
value. It is only of interest RECOMMENDED that registrars authorize whether
the entity in the From field is allowed to register
addresses for the UAS.)

4.3.1 SIP Version

Both address-of-record in the To field.

Contact: The request and response messages include MAY contain a Contact header field. Future
non-REGISTER requests for the version of SIP URI given in use,
and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced
by SIP/2.0) regarding version ordering, compliance requirements, and
upgrading of version numbers. the To header
field SHOULD be compliant with this
specification, applications sending SIP messages MUST include a SIP-
Version of "SIP/2.0". The string is case-insensitive, but
implementations MUST use upper-case.

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

4.4 Option Tags

Option tags are unique identifiers used directed to designate new options in
SIP. These tags are used the address(es) given in Require (Section 6.36), Supported
(Section 6.42) and Unsupported (Section 6.45) header fields.

Syntax:

option-tag = token

See Section C for the definition of token. The creator of
Contact header.

If the request does not contain a new SIP Contact header, the

Handley/Schulzrinne/Schooler/Rosenberg [Page 37] 38]

Internet Draft SIP November 24, 2000

option MUST either prefix the option with their reverse domain name
or register the new option with May 29, 2001

registration remains unchanged.

This is useful to obtain the Internet Assigned Numbers
Authority (IANA).

An example current list of
registrations in the response, as described below.

If a reverse-domain-name option SIP URI in a registration Contact header field differs
from existing registrations according to the rules in
Section 2.1, it is "com.foo.mynewfeature",
whose inventor can be reached at "foo.com". For added to the list of registration. If it
is equivalent, according to these features,
individual organizations are responsible rules, to an existing
registration, all Contact header field parameters for ensuring that option
names do not collide within this
entry are updated accordingly. URIs other than SIP URIs are
compared according to the same domain. The host name part of standard URI equivalency rules
for the option URI schema.

All current registrations MUST use lower-case; share the option name is case-sensitive.

Options registered with IANA do not contain periods and are globally
unique. IANA option tags are case-sensitive.

4.4.1 Registering New Option Tags with IANA

When registering same action value.
Registrations that have a new SIP option, different action than current
registrations for the following information same user MUST be
provided:

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

o 409 (Conflict).

A listing of any new SIP header fields, header proxy server ignores the q parameter
fields or when processing
non-REGISTER requests, while a redirect server simply
returns that parameter values defined by this option. A SIP
option MUSTNOT redefine header fields or parameters defined in
either RFC 2543, any standards-track extensions to RFC 2543,
or other extensions registered through IANA.

o Indication of who has change control over its Contact response header
field.

Having the option (for
example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of
companies);

o A reference proxy server interpret the q parameter is
not sufficient to a further description, if available, guide proxy behavior, as it is not
clear, for
example (in order of preference) an RFC, a published paper, a
patent filing, example, how long it is supposed to wait
between trying addresses.

If the registration is changed while a technical report, documented source code user agent or a
computer manual;

o Contact proxy server
processes an invitation, the new information (postal and email address).

Registrations should SHOULD be sent to iana@iana.org

This procedure has been borrowed from RTSP [4] and used.

7.4 Registration Expiration

An optional "expires" Contact parameter indicates the RTP
AVP [28].

5 Response

Handley/Schulzrinne/Schooler/Rosenberg [Page 38]

Internet Draft SIP November 24, 2000

After receiving and interpreting a request message, desired
expiration time of the recipient
responds with registration. If a SIP response message. The Contact entry does not have
an "expires" parameter, the Expires request and response message format header field
is
shown below:

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

SIP's structure used as the default value. If neither of responses these mechanisms is similar used,
SIP URIs are assumed to [H6], but is defined
explicitly here.

5.1 Status-Line

The first line expire after one hour. Other URI schemes have
no expiration times. Registrations not refreshed after this amount of
time SHOULD be silently discarded.

In a Response message is REGISTER request, the Status-Line, consisting
of client indicates how long it wishes 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
registration to be valid. In the
final CRLF sequence.

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

5.1.1 Status Codes and Reason Phrases

The Status-Code is a 3-digit integer result code that response, the server indicates the
outcome
earliest expiration time of the attempt to understand and satisfy the request. The
Reason-Phrase is intended to give all registrations. If a short textual description of registration
updates an existing registration, the
Status-Code. The Status-Code is intended for use by automata, whereas Expires value of the Reason-Phrase most
recent registration is intended for the human user. The client used, even if it is not
required to examine or display shorter than the Reason-Phrase.

Handley/Schulzrinne/Schooler/Rosenberg [Page 39]

Internet Draft SIP November 24, 2000

extension-code = 3DIGIT
Reason-Phrase = *<TEXT-UTF8, excluding CR, LF>

We provide an overview of the Status-Code below, and provide full
definitions in Section 7. May 29, 2001

registration.

The first digit of registrar determines the Status-Code defines expiration time; it may be longer or
shorter than the class of response. The last two digits do not have any
categorization role. SIP/2.0 allows 6 values for one requested by the first digit:

1xx: Informational -- request received, continuing to process registrand. The REGISTER
response contains the request;

2xx: Success -- actual registration lifetime; the action was successfully received,
understood, client MUST
refresh at least as often and accepted;

3xx: Redirection -- further action needs to be taken in order to
complete SHOULD NOT refresh more frequently. In
general, the request;

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

5xx: Server Error -- expiration time offered by the
user agent. A server failed MAY decide to fulfill an apparently
valid request;

6xx: Global Failure -- lengthen the request cannot be fulfilled at any
server.

Figures 4 through 8 present expiration interval
if, for example, the individual values refresh rate of a particular client exceeds a
threshold.

This behavior is different from RFC 2543, which only allowed
registrars to decrease, but not increase, the numeric
response codes, and an example interval.

Allowing the registrar to set of corresponding reason phrases
for SIP/2.0. These reason phrases are only recommended; they may be
replaced by local equivalents without affecting the protocol. Note
that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response
codes in registration interval
protects it against excessively frequent registration
refreshes while limiting the range starting at x80 state that it needs to avoid conflicts with newly
defined HTTP response codes,
maintain and adds a new class, 6xx, of response
codes.

SIP response codes are extensible. SIP applications are not required
to understand decreasing the meaning of all registered response codes, though
such understanding is obviously desirable. However, applications MUST
understand chance for stale registrations
that require proxying effort.

Registration refreshes SHOULD be sent to the class of any response code, same address as indicated by the first
digit, and treat any unrecognized response
original registration, unless redirected.

7.5 List of Current Registrations

2xx REGISTER responses SHOULD list all current registration in the
Contact header field. An "expires" parameter MUST indicate the
expiration time of the registration.

7.6 Removing Registrations

Registrations expire as being equivalent described above or may be removed explicitly
by setting the expires parameter for an existing registration to zero
or including an Expires: 0 header field. Registrations are matched
based on the
x00 response code of that class, user, host, port and maddr parameters. A client can
remove all registrations by including a single Contact header field
with the exception that an
unrecognized response MUSTNOT be cached. For example, if wildcard address "*". This usage is only allowed in REGISTER
requests when a client
receives an unrecognized response code Expires header with value of 431, zero is present.

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

8 OPTIONS

The OPTIONS method is used to query a server as to its capabilities.
A server that believes it can safely assume
that there was something wrong with its request and treat contact the
response user, such as if it had received a 400 (Bad Request) response code. In
such cases, user agents SHOULD present to agent
where the user the message body
returned with the response, since that message body is likely logged in and has been recently active, MAY respond
to this request with a capability set. A called user agent MAY return

Handley/Schulzrinne/Schooler/Rosenberg [Page 40]

Internet Draft SIP November 24, 2000

include human-readable information which will explain the unusual
status.

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 May 29, 2001

a status codes

6 Header Field Definitions

SIP header fields are similar reflecting how it would have responded to HTTP header fields in both syntax an invitation,
e.g., 600 (Busy). A server SHOULD return Allow, Accept, Accept-
Encoding, Accept-Language and semantics. In particular, SIP Supported header fields follow the syntax for
message-header as described in [H4.2]. fields. The rules for extending header
fields over multiple lines, and use of multiple message-header fields
with response
MAY contain a message body indicating the same field-name, described in [H4.2] also apply to SIP. The
rules in [H4.2] regarding ordering capabilities of header fields apply to SIP,
with the exception end
system (rather than properties of Via fields, see below, whose order matters. any existing call).

The use of the Call-ID header fields required, optional and not applicable field is discussed in Section 10.12. An
OPTIONS requests for each an existing call-id has no impact on that call.

This method are listed in Table 4 MUST be supported by SIP user agents and Table 5. The table uses "o" to
indicate optional, "m" mandatory registrars.

9 Response

After receiving and "-" for not applicable.
"Optional" means that a UA MAY include the header field in interpreting a request
or response, and a UA MAY ignore the header field if present in message, the

Handley/Schulzrinne/Schooler/Rosenberg [Page 41]

Internet Draft recipient
responds with a SIP November 24, 2000

Figure 6: Client error status codes

Server-Error response message. The response message format is
shown below:

Response = "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" Status-Line ; Service Unavailable Section 9.1
*( general-header
| "504" ; Gateway Time-out response-header
| "505" entity-header )
CRLF
[ message-body ] ; SIP Version not supported

Figure 7: Server error status codes

request or response. A "mandatory" request header field MUST be
present in Section 12

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

9.1 Status-Line

The first line of a request, Response message is the Status-Line, consisting
of the protocol version (Section 4.3.1) followed by a numeric
Status-Code and MUST be understood its associated textual phrase, with each element
separated by SP characters. No CR or LF is allowed except in the UAS receiving
final CRLF sequence.

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

9.1.1 Status Codes and Reason Phrases

The Status-Code is a 3-digit integer result code that indicates the
outcome of the attempt to understand and satisfy the request. A mandatory response header field MUST be present in The
Reason-Phrase is intended to give a short textual description of the

Handley/Schulzrinne/Schooler/Rosenberg [Page 42] 41]

Internet Draft SIP November 24, 2000

Global-Failure May 29, 2001

Status-Code. The Status-Code is intended for use by automata, whereas
the Reason-Phrase is intended for the human user. The client is not
required to examine or display the Reason-Phrase.

Status-Code = "600" ; Busy Everywhere Informational ;Fig. 4
| "603" ; Decline Success ;Fig. 4
| "604" ; Does not exist anywhere Redirection ;Fig. 5
| "606" ; Not Acceptable

Figure 8: Global failure status codes

response, and Client-Error ;Fig. 6
| Server-Error ;Fig. 7
| Global-Failure ;Fig. 8
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT-UTF8, excluding CR, LF>

We provide an overview of the header field MUST be understood by Status-Code below, and provide full
definitions in Section 11. The first digit of the UAC
processing Status-Code defines
the class of response. "Not applicable" means The last two digits do not have any
categorization role. SIP/2.0 allows 6 values for request header
fields that the header field MUSTNOT be present in a request. If one
is placed in a first digit:

1xx: Informational -- request by mistake, it MUST be ignored by received, continuing to process
the UAS
receiving request;

2xx: Success -- the request. Similarly, a header field labeled "not
applicable" for a response means that the UAS MUSTNOT place the
header in the response, action was successfully received,
understood, and the UAC MUST ignore the header in the
response. "m*" indicates a header that SHOULD be sent, but servers
need accepted;

3xx: Redirection -- further action needs to be prepared taken in order to receive requests without that header field. A
"*" indicates that
complete the header fields are needed only if message body
is not empty. See sections 6.19, 6.20 and 8 for details.

The "where" column describes request;

4xx: Client Error -- the request and response types with
which the header field can contains bad syntax or cannot
be used. "R" refers fulfilled at this server;

5xx: Server Error -- the server failed to header fields that
can be used in requests (that is, fulfill an apparently
valid request;

6xx: Global Failure -- the request and general header fields).
"r" designates a response or general-header field as applicable to
all responses, while a list cannot be fulfilled at any
server.

Figures 4 through 8 present the individual values of the numeric values indicates
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 the status protocol. Note
that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response
codes with which in the header field can be used. "g" and "e" designate
general (Section 6.1) range starting at x80 to avoid conflicts with newly
defined HTTP response codes, and entity header (Section 6.2) fields,
respectively. If adds a header field is marked "c", it is copied from the
request new class, 6xx, of response
codes.

Handley/Schulzrinne/Schooler/Rosenberg [Page 42]

Internet Draft SIP May 29, 2001

SIP response codes are extensible. SIP applications are not required
to understand the response.

The "proxy" column describes whether proxies can add comma-separated
elements to headers ("c", for concatenate or comma), can modify meaning of all registered response codes, though
such understanding is obviously desirable. However, applications MUST
understand the
header ("m"), can add class of any response code, as indicated by the header if not present ("a") or need first
digit, and treat any unrecognized response as being equivalent to read the header ("r"). Headers
x00 response code of that need to be read cannot class. However, proxies SHOULD distinguish
100 from other 1xx responses. (The former SHOULD NOT be encrypted.
Proxies MUSTNOT alter any fields that are authenticated (see forwarded,
while the latter MUST be. See Section
13.2), but MAY add copies 17.3.) For example, if a
client receives an unrecognized response code of fields 431, it can safely
assume that were authenticated by there was something wrong with its request and treat the UA
response as if indicated in it had received a 400 (Bad Request) response code. In
such cases, user agents SHOULD present to the table. Depending on local policy, proxies MAY
inspect any non-encrypted header fields and MAY modify any non-
authenticated header field, but proxies cannot rely on fields other
than user the ones indicated in message body
returned with the table to be readable or modifiable.

If authentication response, since that message body is used, likely to
include human-readable information which will explain the rules in Section 13.2 apply. Proxies
SHOULDNOT re-order header fields.

Handley/Schulzrinne/Schooler/Rosenberg [Page 43]

Internet Draft unusual
status.

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

10 Header Field Definitions

Handley/Schulzrinne/Schooler/Rosenberg [Page 43]

Internet Draft SIP May 29, 2001

Figure 6: Client error status codes

Figure 7: Server error status codes

SIP header fields are similar to HTTP header fields in both syntax
and semantics. In particular, SIP header fields follow the syntax for
message-header as described in [H4.2]. The rules for extending header

Handley/Schulzrinne/Schooler/Rosenberg [Page 44]

Internet Draft SIP May 29, 2001

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

Figure 8: Global failure status codes

fields over multiple lines, and use of multiple message-header fields
with 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,
with the exception of Via fields, see below, whose order matters.

The header fields required, optional and not applicable for each
method are listed in Table 4 and Table 5. The table uses "o" to
indicate optional, "m" mandatory and "-" for not applicable.
"Optional" means that a UA MAY include the header field in a request
or response, and a UA MAY ignore the header field if present in the
request or response. A "mandatory" request header field MUST be
present in a request, and MUST be understood by the UAS receiving the
request. A mandatory response header field MUST be present in the
response, and the header field MUST be understood by the UAC
processing the response. "Not applicable" means for request header
fields that the header field MUST NOT be present in a request. If
one is placed in a request by mistake, it MUST be ignored by the UAS
receiving the request. Similarly, a header field labeled "not
applicable" for a response means that the UAS MUST NOT place the
header in the response, and the UAC MUST ignore the header in the
response. "m*" indicates a header that SHOULD be sent, but servers
need to be prepared to receive requests without that header field. A
"*" indicates that the header fields are required if the message body
is not empty. See sections 10.18, 10.19 and 12 for details.

The "where" column describes the request and response types with
which the header field can be used. "R" refers to header fields that
can be used in requests (that is, request and general header fields).
"r" designates a response or general-header field as applicable to
all responses, while a list of numeric values indicates the status
codes with which the header field can be used. "g" and "e" designate
general (Section 10.1) and entity header (Section 10.2) fields,
respectively. If a header field is marked "c", it is copied from the
request to the response.

The "proxy" column describes whether proxies can add comma-separated
elements to headers ("c", for concatenate or comma), can modify the

Handley/Schulzrinne/Schooler/Rosenberg [Page 45]

Internet Draft SIP May 29, 2001

header ("m"), can add the header if not present ("a") or need to read
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 that were authenticated by the UA
if indicated in the table. Depending on local policy, proxies MAY
inspect any non-encrypted header fields and MAY modify any non-
authenticated header field, but proxies cannot rely on fields other
than the ones indicated in the table to be readable or modifiable.

If authentication is used, the rules in Section 18.2 apply. Proxies
SHOULD NOT re-order header fields.

Other header fields can be added as required; a server MUST ignore
header fields not defined in this specification that it does not
understand. A proxy MUST NOT remove or modify header fields not
defined in this specification that it does not understand. A compact
form of these header fields is also defined in Section 13 for use
over UDP when the request has to fit into a single packet and size is
an issue.

Table 6 in Appendix A lists those header fields that different client
and server types MUST be able to parse.

10.1 General Header Fields

General header fields apply to both request and response messages.
The "general-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 of general
header fields if all parties in the communication recognize them to
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 the
message-body or, if no body is present, about the resource identified
by the request. The term "entity header" is an HTTP 1.1 term where
the response body can contain a transformed version of the message
body. The original message body is referred to as the "entity". We
retain the same terminology for header fields but usually refer to
the "message body" rather then the entity as the two are the same in
SIP.

10.3 Request Header Fields

Handley/Schulzrinne/Schooler/Rosenberg [Page 46]

Internet Draft SIP May 29, 2001

Header field where 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 200 - - - 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 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 of header fields, A--O

The "request-header" fields allow the client to pass additional
information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics
equivalent to the parameters of a programming language method
invocation.

Handley/Schulzrinne/Schooler/Rosenberg [Page 47]

Internet Draft SIP May 29, 2001

Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Priority R 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 R o o o o o o
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 of header fields, P--Z; (1): copied with possible
addition of tag

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 of "request-
header" fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as
"entity-header" fields.

10.4 Response Header Fields

The "response-header" fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields give information about the server 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 of "response-

Handley/Schulzrinne/Schooler/Rosenberg [Page 48]

Internet Draft SIP May 29, 2001

header" fields if all parties in the communication recognize them to
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 the same generic header format as that
given in Section 3.1 of RFC 822 [25]. Each header field consists of a
name followed by a colon (":") and the field value. Field names are
case-insensitive. The field value MAY be preceded by any amount of
leading white space (LWS), though a single space (SP) is preferred.
Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or horizontal tab (HT). Applications
MUST follow HTTP "common form" when generating these constructs,
since there might exist some implementations that fail to accept
anything beyond the common forms.

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

The relative order of header fields with different field names is not
significant. Multiple header fields with the same field-name may be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list (i.e., #(values)).
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.

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

The Contact, From and To header fields contain a URL. If the URL
contains a comma, question mark or semicolon, the URL MUST be
enclosed in angle brackets (< and >). Any URL parameters are

Handley/Schulzrinne/Schooler/Rosenberg [Page 49]

Internet Draft SIP May 29, 2001

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 the exception that if no Accept
header is present, the server SHOULD assume a default value of
application/sdp

As a request-header field, it is 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 the content-codings [H3.5] that are acceptable in the
response. See [H14.3]. The syntax of this header is defined in
[H14.3]. The semantics in SIP are identical to those defined in
[H14.3].

Note: An empty Accept-Encoding header field is permissible,
even though the syntax 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 header field is present in a request, the
server MUST use the "identity" encoding.

HTTP/1.1 [H14.3] states that the server SHOULD use the
"identity" encoding unless it has additional information
about the capabilities of the client. This is needed for
backwards-compatibility with old HTTP clients and does not
affect SIP.

Handley/Schulzrinne/Schooler/Rosenberg [Page 50]

Internet Draft SIP May 29, 2001

10.8 Accept-Language

The Accept-Language general-header follows the syntax defined in
[H14.4]. The rules for ordering the languages based on the q
parameter apply to SIP as well. When used in SIP, the Accept-Language
general-header field can be used to allow the client to indicate to
the server in which language it would prefer to receive reason
phrases, session descriptions or status responses carried as message
bodies. A proxy MAY use this field to help select the destination for
the call, for example, a human operator conversant in a language
spoken by the caller.

Example:

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

10.9 Alert-Info

The Alert-Info header field indicates that the content indicated in
the URLs should be rendered instead of ring tone. A user SHOULD be
able to disable this feature selectively to prevent unauthorized
disruptions.

Alert-Info = "Alert-Info" ":" # ( "<" URI ">" *( ";" generic-param ))
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 the set of methods supported by the
resource identified by the Request-URI. The purpose of this field is
strictly to inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response, SHOULD be present in an OPTIONS response SHOULD be
present in the 200 (OK) response to the initial INVITE for a call and
MAY be present in final responses for other methods. All methods,
including ACK and CANCEL, understood by the UAS are included.

Handley/Schulzrinne/Schooler/Rosenberg [Page 51]

Internet Draft SIP May 29, 2001

The Allow header field MAY also be included in requests, to indicate
the requestor's capabilities for this Call-ID.

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

Allow = "Allow" ":" 1#Method

10.11 Authorization

A user agent that wishes to authenticate itself with a UAS or
registrar -- usually, but not necessarily, after receiving a 401
response -- MAY do so by including an Authorization header field with
the request. The Authorization field value consists of credentials
containing the authentication information of the user agent for the
realm of the resource being requested.

Section 18.2 overviews the use of the Authorization 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 a particular
invitation or all registrations of a particular client. Note that a
single multimedia conference can give rise to several calls with
different Call-IDs, e.g., if a user invites a single individual
several times to the same (long-running) conference.

For an INVITE request, a callee user agent server SHOULD NOT alert
the user if the user has responded previously to the Call-ID in the
INVITE request. If the user is already a member of the conference and
the conference parameters contained in the session description have
not changed, a callee user agent server MAY silently accept the call,
regardless of the Call-ID. An invitation for an existing Call-ID or
session can change the parameters of the conference. A client
application MAY decide to simply indicate to the user that the
conference parameters 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, the client MAY use identifiers within
the session description to detect this duplication. For example, SDP
contains a session id and version number in the origin (o) field.

Handley/Schulzrinne/Schooler/Rosenberg [Page 52]

Internet Draft SIP November 24, 2000

Header May 29, 2001

The REGISTER and OPTIONS methods use the Call-ID value (in addition
to the CSeq value) to unambiguously match requests and responses. All
REGISTER requests issued by a single client SHOULD use the same
Call-ID, at least within the same boot cycle. For these requests, it
makes no difference whether the Call-ID value matches an existing
call or not.

Since the Call-ID is generated by and for SIP, there is no
reason to deal with the complexity 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 be
reused for later calls. Use of cryptographically random identifiers
[28] 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 with third-party
control.

For systems which have tight bandwidth constraints, many of the
mandatory SIP headers have a compact form, as discussed in Section
13. These are alternate names for the headers which occupy less space
in the message. In the case of Call-ID, the compact form is i.

For example, both of 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

Handley/Schulzrinne/Schooler/Rosenberg [Page 53]

Internet Draft SIP May 29, 2001

The Call-Info general header field provides additional information
about the caller or callee, depending on whether it is found 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 of the caller or callee; "info" describes the caller
or callee in general, e.g., through a web page; "card" provides a
business card (e.g., in vCard [29] or LDIF [30] formats).

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 this specification, the Contact
general-header field can appear in INVITE, OPTIONS, ACK, and REGISTER
requests, and in 1xx, 2xx, 3xx, and 485 responses. Other methods
defined elsewhere may allow or require the use of the Contact header
field. This is generally necessary if the recipient of this method
needs to send requests to the originator. In general, it provides a
URL where the user can be reached for further communications.

In some of the cases below, the client uses information from the
Contact header field in Request-URI of future requests. In these
cases, the client copies all but the "method-param" and "header"
elements of the addr-spec part of the Contact header field where into the
Request-URI of the request. It uses the "header" parameters to create
headers for the request, replacing any default headers normally used.
Unless the client is configured to use a default proxy for all
outgoing requests, it then directs the request to the address and
port specified by the "maddr" and "port" parameters, using the
transport protocol given 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 BYE CAN INV OPT REG
__________________________________________________________
Accept R - o o o o o
Accept 415 - o o o o o
Accept r - - - o o o
Accept-Encoding R - o o o o o
Accept-Encoding 415 - o o o o o
Accept-Language R - o o 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 200 - - - o o o
Allow 405 m m m m m m
Also R - o - - - -
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 requests: INVITE requests MUST, and ACK
requests MAY contain a single Contact R o - - m o o header indicating a
single URI from which location the request is originating.

Handley/Schulzrinne/Schooler/Rosenberg [Page 54]

Internet Draft SIP May 29, 2001

The URI SHOULD contain the address of the client itself
(i.e., its IP address, or a FQDN for the host, or an SRV
record with the highest priority entry beingan FQDN of that
host). See Section 16 for usage of the Contact header for
routing subsequent requests. For OPTIONS, Contact provides
a hint where future SIP requests can be sent or the user
can be contacted via non-SIP means.

This allows the callee to send future requests, such
as BYE, directly to the caller instead of through a
series of proxies. The Via header is not sufficient
since the desired address may be that of a proxy.

INVITE 1xx responses: A UAS sending a provisional response (1xx)
MAY insert a Contact response header. It has the same
semantics in a 1xx response as a 2xx INVITE response. Note
that CANCEL requests MUST NOT be sent to that address, but
rather follow the same path as the original request.

INVITE and OPTIONS 2xx responses: A user agent server sending a
definitive, positive response (2xx) MUST insert a single
Contact response header field indicating a single SIP URI
under which it is reachable most directly for future SIP
requests, such as ACK, within the same call leg. The URI
SHOULD contain the address of the server itself (i.e., its
IP address, or a FQDN for the host, or an SRV record with
the highest priority entry beingan FQDN of that host). See
Section 16 for usage of the Contact header for routing
subsequent requests.

If a UA supports both UDP and TCP, it SHOULD NOT indicate a
transport parameter in the URI.

The Contact 1xx - - - o o - value SHOULD NOT be cached across calls,
as it may not represent the most desirable location
for a particular destination address.

REGISTER requests and responses: See Section 7. The Contact 2xx - - - m o o
header value of "*" is only used in REGISTER requests.

3xx and 485 responses: The Contact response-header field can be
used with a 3xx - o - o o o or 485 (Ambiguous) response codes to
indicate one or more alternate addresses to try. It can
appear in responses to BYE, INVITE and OPTIONS methods. The
Contact header field contains URIs giving the new locations
or user names to try, or may simply specify additional

Handley/Schulzrinne/Schooler/Rosenberg [Page 55]

Internet Draft SIP May 29, 2001

transport parameters. A 300 (Multiple Choices), 301 (Moved
Permanently), 302 (Moved Temporarily) or 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 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 (Ambiguous)
response SHOULD contain a Contact field containing URIs of
new addresses to 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 to try or a change of
SIP transport from UDP to TCP or vice versa. The client
copies information from the Contact header field into the
Request-URI as described above.

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

Note that the Contact header field MAY 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 any suitable URI
indicating where the called party 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 a mailto: (RFC 2368, [31]) URL.

The following parameters are defined. Additional parameters may be
defined in other specifications.

q: The "qvalue" indicates the relative preference among the
locations given. "qvalue" values are decimal numbers from 0
to 1, with higher values indicating higher preference. The
default value is 0.5.

action: The "action" parameter is used only when registering
with the REGISTER request. It indicates whether the client
wishes that the server proxy or redirect future requests
intended for the client. If this parameter is not specified
the action taken depends on server configuration. In its
response, the registrar SHOULD indicate the mode used. This
parameter is ignored for other requests.

expires: The "expires" parameter indicates how long the URI is
valid. The parameter is either 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 number indicating seconds
or a quoted string containing a SIP-date. If this parameter
is not provided, the value of the Expires header fields, A--O

Other field
determines how long the URI is valid. Implementations MAY
treat values larger than 2**32-1 (4294967295 seconds or 136

Handley/Schulzrinne/Schooler/Rosenberg [Page 56]

Internet Draft SIP May 29, 2001

years) as equivalent to 2**32-1.

Contact = ( "Contact" | "m" ) ":"
("*" | (1# (( name-addr | addr-spec )
[ *( ";" contact-params ) ] [ comment ] )))

name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI
display-name = *token | quoted-string

extension-attribute = extension-name [ "=" extension-value ]

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

The Contact header fields field fulfills functionality similar to
the Location header field in HTTP. However, the HTTP header
only allows one address, unquoted. Since URIs can be added contain
commas and semicolons as required; 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 the use 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

Content-Disposition = "Content-Disposition" ":"

Handley/Schulzrinne/Schooler/Rosenberg [Page 57]

Internet Draft SIP May 29, 2001

The Content-Disposition header field describes how the message body
or, in the case of multipart messages, a server MUST ignore message body part is to be
interpreted by the UAC or UAS. The SIP header fields extends the MIME
Content-Type (RFC 1806 [32]).

The value "session" indicates that the body part describes a session,
for either calls or early (pre-call) media. The value "render"
indicates that the body part should be displayed or otherwise
rendered to the user. For backward-compatibility, if the Content-
Disposition header is not defined in this specification missing, bodies of Content-Type
application/sdp imply the disposition "session", while other content
types imply "render".

The disposition type "icon" indicates that the body part contains an
image suitable as an iconic representation of the caller or callee.
The value "alert" indicates that the body part contains information,
such as an audio clip, that should be rendered instead of ring tone.

The handling parameter, handling-parm, describes how the UAS should
react if it does not
understand. A proxy MUSTNOT remove receives a message body whose content type or modify header fields not
defined in this specification that disposition
type it does not understand. A compact
form of these If the parameter has the value
"optional", the UAS MUST ignore the message body; if it has the value
"required", the UAS MUST return 415 (Unsupported Media Type). If the
handling parameter is missing, the value "required" is to be assumed.

If this header fields field is also defined in Section 9 for use over 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 is used as a modifier to the
"media-type". When present, its value indicates what additional

Handley/Schulzrinne/Schooler/Rosenberg [Page 44] 58]

Internet Draft SIP November 24, 2000

Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________________
Priority R May 29, 2001

content codings have been applied to the entity-body, and thus what
decoding mechanisms MUST be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow 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 R - - - - - 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 R o o o o o o
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 body to be compressed without losing the
identity of its underlying media type.

If multiple encodings have been applied to an entity, the content
codings MUST be listed in the order in which they were applied.

All content-coding values are case-insensitive. The Internet Assigned
Numbers Authority (IANA) acts as a registry for content-coding value
tokens. See [H3.5] for a definition of the syntax for content-coding.

Clients MAY apply content encodings to the body in requests. If the
server is not capable of decoding the body, or does not recognize any
of the content-coding values, it MUST send a 415 "Unsupported Media
Type" response, listing acceptable encodings in the Accept-Encoding
header. A server MAY apply content encodings to the bodies in
responses. The server MUST only use encodings listed in the Accept-
Encoding header fields, P--Z; (1): copied with possible
addition in the request.

10.17 Content-Language

See [H14.12].

10.18 Content-Length

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

UDP when the request has
message-body, in decimal number of octets, sent to fit into a single packet and the recipient.

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

An example is

Content-Length: 3495

Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity. (The size of the message-body does not include the CRLF
separating headers and body.) Any Content-Length greater than or
equal to zero is an
issue.

Table 6 a valid value. If no body is present in Appendix A lists those a message,
then the Content-Length header fields that different client
and server types field MUST be able to parse.

6.1 General Header Fields

General header fields apply set to both zero. If a
server receives a datagram request without Content-Length, it MUST

Handley/Schulzrinne/Schooler/Rosenberg [Page 59]

Internet Draft SIP May 29, 2001

assume that the request encompasses the remainder of the packet. If a
server receives a datagram request and response messages.
The "general-header" field names can be extended reliably only in
combination with a change Content-Length, but the
value differs from the size of the body sent in the protocol version. However, new request, the
server SHOULD return a 400 (Bad Request) response.

If a response does not contain a Content-Length, the client assumes
that it encompasses the remainder of the datagram packet or
experimental the data
until the stream connection is closed, as applicable. Section 12
describes how to determine the length of the message body.

The ability to omit Content-Length simplifies the creation
of cgi-like scripts that dynamically generate responses.

10.19 Content-Type

The Content-Type entity-header field indicates the media type of the
message-body sent to the recipient. The "media-type" element is
defined in [H3.7]. The Content-Type header fields MAY MUST be given present if the semantics of general
body is not empty. If the body is empty, and a Content-Length header fields
is present, it indicates that the body of the specific type has zero
length (for example, if all parties in 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 communication recognize them CSeq (command sequence) general-header field to
be "general-header" fields. Unrecognized
every request. A CSeq header fields are treated field in a request contains the request
method and a single decimal sequence number. The sequence number MUST
be expressible as
"entity-header" fields. a 32-bit unsigned integer. A server MUST echo the
CSeq value from the request in its response. The CSeq header serves
to order transactions within a call leg, and to provide a means to
uniquely identify transactions.

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

Handley/Schulzrinne/Schooler/Rosenberg [Page 45] 60]

Internet Draft SIP November 24, 2000

6.2 Entity Header Fields

The "entity-header" fields define meta-information about the
message-body or, if no body is present, about May 29, 2001

For requests that are outside of a call leg, or for a request that
initiates a session, the resource identified
by value of the request. The term "entity header" sequence number is arbitrary,
but MUST be less than 2**31. For requests which are subsequent ones
within an HTTP 1.1 term where existing call leg (such as a re-INVITE or BYE), the response body can CSeq
header MUST contain strictly monotonically increasing and contiguous
(increasing-by-one) sequence numbers; sequence numbers do not wrap
around. Retransmissions of the same request carry the same CSeq
value.

For requests outside of a transformed version call leg, ordering is irrelevant, and so
the value of the message
body. CSeq number in requests received by a UAS is not
important. For 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 original message body server MUST reject, using a
400 class response, any request within a call leg with a lower
sequence number. Any request that is referred to as received with a sequence number
higher than the "entity". We
retain highest received so far (even it is higher by more
than one), SHOULD be accepted.

If a client initiates a session, and receives multiple 200 class
responses, each establishes a separate call leg. For subsequent
requests within each of those call legs (each of which differs only
by the same terminology for header fields but usually refer to tag in the "message body" rather then To field), the entity as CSeq numbers increment independently
from the two are other call legs. Furthermore, the same CSeq numbering space is
unique in
SIP.

6.3 Request Header Fields

The "request-header" fields allow each direction. That is, the client CSeq values in requests from A
to pass additional
information about the request, and about B are independent of the client itself, values in requests from B to A.

The ACK request MUST contain the
server. These fields act same CSeq numeric value as the
INVITE request modifiers, that it refers to, but with semantics
equivalent to the parameters of a programming language method
invocation. Method of "ACK". The "request-header" field names can be extended reliably only in
combination with a change in
CANCEL request MUST contain the protocol version. However, new or
experimental header fields MAY be given same CSeq numeric value as the semantics
request it cancels, but with a Method of "request-
header" fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as
"entity-header" fields.

6.4 Response Header Fields "CANCEL".

The "response-header" fields allow Method value allows the server client to pass additional
information about distinguish the response which cannot be placed in the Status-
Line. These header fields give information about the server and about
further access to a
CANCEL request from that of the resource identified by the Request-URI.

Response-header field names request it is cancelling. CANCEL
requests can be extended reliably only in
combination generated by proxies; if they were to increase the
sequence number, it might conflict with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of "response-
header" fields if all parties in later request issued by the communication recognize them to
be "response-header" fields. Unrecognized header fields are treated
as "entity-header" fields.

6.5 Header Field Format

Header fields ("general-header", "request-header", "response-header",
and "entity-header") follow
user agent for the same generic header format as that
given in Section 3.1 of RFC 822 [26]. Each header field consists call.

With a length of 32 bits, a
name followed by server could generate, within a colon (":") and the field value. Field names are
case-insensitive. single
call, one request a second for about 136 years before needing to wrap
around. The field initial value MAY be preceded by any amount of
leading white space (LWS), though a single space (SP) the sequence number is preferred. chosen so that
subsequent requests within the same call will not wrap around. A
non-zero initial value allows to use a time-based initial sequence
number, if the client desires. A client could, for example, choose
the 31 most significant bits of a 32-bit second clock as an initial
sequence number.

Example:

Handley/Schulzrinne/Schooler/Rosenberg [Page 46] 61]

Internet Draft SIP November 24, 2000

Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or horizontal tab (HT). Applications
MUST follow HTTP "common form" when generating these constructs,
since there might exist some implementations that fail to accept
anything beyond the common forms.

message-header May 29, 2001

CSeq: 4711 INVITE

10.21 Date

Date is a general-header field. Its syntax is:

Date = field-name "Date" ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content SIP-date
SIP-date = < rfc1123-date

See [H14.18] for a definition of rfc1123-date. Note that unlike
HTTP/1.1, SIP only supports the OCTETs making up most recent RFC 1123 [33] formatting
for dates. As in [H3.3], SIP restricts the field-value timezone in SIP-date to
"GMT", while RFC 1123 allows any timezone.

The consistent use of GMT between Date, Expires and consisting Retry-
After headers allows implementation of either *TEXT-UTF8
or combinations simple clients that
do not have a notion of token,
separators, and quoted-string> absolute time. Note that rfc1123-
date is case-sensitive.

The relative order of Date header fields with different field names reflects the time when the request or response
is not
significant. Multiple header fields with first sent. Thus, retransmissions have the same field-name may be
present Date header field
value as the original.

Registrars MUST include this header in a message REGISTER responses if they use
absolute expiration times and only if the entire field-value SHOULD include it for that all responses.

The Date header field is defined as a comma-separated list (i.e., #(values)).
It MUST can be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, used by appending each subsequent field-value simple end systems
without a battery-backed clock to the first, each
separated by acquire a comma. The order notion of
current time. However, in which header fields with the same
field-name are received is therefore significant its GMT-form, it requires clients
to know their offset from GMT.

10.22 Encryption

The Encryption general-header field specifies that the
interpretation of content has
been encrypted. Section 18 describes the combined field value, overall SIP security
architecture and thus a proxy MUSTNOT
change the order of these algorithms. This header field values when a message is forwarded.

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

The Contact, From and To header fields contain a URL. If the URL
contains a comma, question mark or semicolon, the URL MUST be
enclosed in angle brackets (< intended for end-
to-end encryption of requests and >). Any URL parameters responses. Requests are
contained within these brackets. If encrypted
based on the URL is not enclosed public key belonging to the entity named in angle
brackets, any semicolon-delimited parameters are header-parameters,
not URL parameters.

6.6 Accept

The Accept the To
header follows field. Responses are encrypted based on the syntax defined public key
conveyed in [H14.1]. The
semantics are also identical, with the exception that if no Accept Response-Key header is present, field. Note that the server SHOULD assume a default value of
application/sdp

As a request-header field, it is public keys
themselves may not be used only with those methods that for the encryption. This depends on the
particular algorithms used.

Handley/Schulzrinne/Schooler/Rosenberg [Page 47] 62]

Internet Draft SIP November 24, 2000

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

6.7 Accept-Encoding

The Accept-Encoding general-header field is similar to Accept, but
restricts the content-codings [H3.4.1] that are acceptable in May 29, 2001

For any encrypted message, at least the
response. See [H14.3]. The syntax of this message body and possibly
other message header is defined in
[H14.3]. The semantics in SIP fields are identical to those defined in
[H14.3].

Note: encrypted. An empty Accept-Encoding application receiving a
request or response containing an Encryption header field is permissible,
even though decrypts
the syntax in [H14.3] does not provide for it.
It is equivalent body and then concatenates the plaintext to Accept-Encoding: identity, i.e., only the identity encoding, meaning no encoding, is permissible.

If no Accept-Encoding header field is present in a request, request line and
headers of the
server MUST use original message. Message headers in the "identity" encoding.

HTTP/1.1 [H14.3] states that decrypted
part completely replace those with the server SHOULD use same field name in the
"identity" encoding unless it has additional information
about
plaintext part. (Note: If only the capabilities body of the client. This message is needed for
backwards-compatibility to be
encrypted, the body has to be prefixed with old HTTP clients CRLF to allow proper
concatenation.) Note that the request method and does not
affect SIP.

6.8 Accept-Language

The Accept-Language general-header follows Request-URI cannot
be encrypted.

Encryption only provides privacy; the syntax defined recipient has no
guarantee that the request or response came from the party
listed in
[H14.4]. The rules for ordering the languages based on From message header, only that the q
parameter apply to SIP as well. When sender
used in SIP, the Accept-Language
general-header field can recipient's public key. However, proxies will not
be used able to allow modify the client to indicate to request or response.

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

The token indicates the server in which language form of encryption used; it would prefer to receive reason
phrases, session descriptions or status responses carried as message
bodies. A proxy MAY use this field to help select 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" header fields will reach the same destination for
the call, for example, a human operator conversant in as an
otherwise identical un-encrypted request.

10.23 Error-Info

The Error-Info response header provides a language
spoken by pointer to additional
information about the caller.

Handley/Schulzrinne/Schooler/Rosenberg [Page 48]

Internet Draft SIP November 24, 2000

Example:

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

6.9 Alert-Info

The Alert-Info error status response. This header field indicates that the content indicated is
only contained in
the URLs should be rendered instead of ring tone. A user SHOULD be
able to disable this feature selectively to prevent unauthorized
disruptions.

Alert-Info 3xx, 4xx, 5xx and 6xx responses.

Error-Info = "Alert-Info" "Error-Info" ":" # ( "<" URI ">" *( ";" generic-param ))
generic-param = token [ "=" ( token | host | quoted-string ) ]

Example:

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

6.10 Allow

The Allow header field lists the set of methods supported by the
resource identified by the Request-URI.

10.24 Expires

The purpose of this field is
strictly to inform the recipient of valid methods associated with the
resource. An Allow header Expires entity-header field MUST be present in a 405 (Method Not
Allowed) response, SHOULD be present in an OPTIONS response SHOULD be
present in the 200 (OK) response to gives the initial INVITE for a call and
MAY be present in final responses for other methods. All methods,
including ACK date and CANCEL, understood by the UAS are included.

The Allow header field MAY also be included in requests, to indicate
the requestor's capabilities for this Call-ID.

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

Allow = "Allow" ":" 1#Method time after which

Handley/Schulzrinne/Schooler/Rosenberg [Page 49] 63]

Internet Draft SIP November 24, 2000

6.11 Also

The Also May 29, 2001

the message content expires.

This header field is used currently defined only in BYE requests. It indicates to for the
receiving UA that it should initiate an REGISTER, as
described in Section 7, and INVITE request to the
addresses indicated. The BYE request takes effect regardless of
whether the methods.

For INVITE succeeds and requests, it is responded to immediately.

This mechanism allows unsupervised call transfer.

Also = "Also" ":" 1# (( name-addr | addr-spec )

6.12 Authorization

A user agent that wishes to authenticate itself with a UAS or
registrar -- usually, but not necessarily, after receiving request and response-header field. In a 401
response -- MAY do so by including an Authorization header field with
request, the request. For PGP, Authorization caller can also protect responses. The
Authorization field value consists of credentials containing limit the
authentication information validity of the user agent an invitation, for
example, if a client wants to limit the realm of the
resource being requested.

Section 13.2 overviews the use time duration of the Authorization header field, and
Section 15 describes the syntax and semantics when used with PGP-
based authentication.

6.13 Call-ID

The Call-ID general-header field uniquely identifies a particular
invitation search or all registrations of a particular client. Note that
a
single multimedia conference can give rise to several calls with
different Call-IDs, e.g., if a invitation. A user invites interface MAY take this as a single individual
several times hint to
leave the same (long-running) conference.

For an INVITE request, a callee user agent server SHOULDNOT alert invitation window on the
user screen even if the user has responded previously to is not
currently at the Call-ID in workstation. This also limits the duration of a
search. If the request expires before the search completes, the proxy
returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily)
response, a server can advise the
INVITE request. If client of the user is already a member maximal duration of
the conference and redirection.

Note that the conference parameters contained in expiration time does not affect the duration of the
actual session that may result from the invitation. Session
description have
not changed, a callee user agent server MAY silently accept protocols may offer the call,
regardless of ability to express time limits on
the Call-ID. An invitation for an existing Call-ID or session duration, however.

The value of this field can change be either a SIP-date or an integer number
of seconds (in decimal), measured from the parameters receipt of the conference. A client
application request.
The latter approach is preferable for short durations, as it does not
depend on clients and servers sharing a synchronized clock.
Implementations MAY decide to simply indicate treat values larger than 2**32-1 (4294967295 or
136 years) as equivalent to the user that the
conference parameters have been changed 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 and accept responses MUST contain a From general-header field,
indicating the invitation
automatically or it MAY require user confirmation.

Handley/Schulzrinne/Schooler/Rosenberg [Page 50]

Internet Draft SIP November 24, 2000

A user initiator of the request. (Note that this may be invited to
different from the initiator of the same conference or call using several
different Call-IDs. If desired, leg. Requests sent by the client MAY
callee to the caller use identifiers within the session description callee's address in the From header
field.) The From field MUST contain the "tag" parameter. However, a
server MUST be prepared to detect this duplication. For example, SDP
contains receive a session id and version number request without a tag, in which

Handley/Schulzrinne/Schooler/Rosenberg [Page 64]

Internet Draft SIP May 29, 2001

case the origin (o) field. tag is considered to effectively have a value of zero. This
is to maintain backwards compatibility with RFC2543, which did not
mandate From tags. . The REGISTER and OPTIONS methods use server copies the Call-ID value (in addition From header field from
the request to the CSeq value) response. The optional "display-name" is meant to unambiguously match requests and responses. All
REGISTER requests issued
be rendered by a single client human-user interface. A system SHOULD use the same
Call-ID, at least within the same boot cycle. For these requests, it
makes no difference whether
display name "Anonymous" if the Call-ID value matches an existing
call or not.

Since identity of the Call-ID is generated by and for SIP, there client is no
reason to deal remain
hidden.

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

Even if the complexity of URL-encoding and
case-ignoring string comparison.

callid = token [ "@" token ]
Call-ID "display-name" is empty, the "name-addr" form MUST be
used if the "addr-spec" contains a comma, question mark, or
semicolon. Syntax issues are discussed in Section 10.5.

From = ( "Call-ID" "From" | "i" "f" ) ":" callid ( 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 callid "tag" value MUST be a globally unique identifier and MUSTNOT be reused cryptographically random
with at least 32 bits of randomness. It SHOULD differ for later calls. Use each call
leg.

For the purpose of cryptographically random identifiers [29] identifying call legs, two From or To header
fields are equal if and only if:

o The addr-spec component is
RECOMMENDED. Implementations MAY use equal, according to the form "localid@host". Call-
IDs are case-sensitive rules in
Section 2.1.

o Any "tag" and "generic-param" parameters are simply equal, compared byte-by-byte.

Using cryptographically random identifiers provides some
protection against session hijacking.
according to the case-sensitivity rules in Section 10. Only
parameters that appear in both header fields are compared.

Handley/Schulzrinne/Schooler/Rosenberg [Page 65]

Internet Draft SIP May 29, 2001

Call-ID, To and From are needed to identify a call leg.
The distinction between call and call leg matters in calls
with third-party
control.

For multiple responses to a forked request. The format is
similar to the equivalent RFC 822 [25] header, but with a
URI instead of just an email address.

10.26 In-Reply-To

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

This allows automatic call distribution systems which have tight bandwidth constraints, many to route
return calls to the originator of the
mandatory SIP headers 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 compact form, as discussed in Section 9.
These are alternate names substitute for request authentication.

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

The Max-Forwards request-header field may be used with any SIP method
to limit the headers number of proxies or gateways that can forward the
request to the next downstream server. This can also be useful when
the client is attempting to trace a request chain which occupy less space appears to be
failing or looping in mid-chain.

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

The Max-Forwards value is a decimal integer indicating the message. In the case remaining
number of Call-ID, the compact form times this request message is i.

For example, both allowed to be forwarded.

Each proxy or gateway recipient of a request containing a Max-
Forwards header field MUST check and update its value prior to
forwarding the request. If the received value is zero (0), the following are valid:

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

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

Handley/Schulzrinne/Schooler/Rosenberg [Page 51] 66]

Internet Draft SIP November 24, 2000

6.14 Call-Info

The Call-Info general header field provides additional information
about May 29, 2001

recipient MUST NOT forward the caller or callee, depending on whether it request and returns 483 (Too many
hops). Instead, a server MAY act as a final recipient for OPTIONS
requests. It is found RECOMMENDED that the server include Supported, Server
and Allow header fields in a
request or the response. The purpose of

If the URI received Max-Forwards value is described by greater than zero, then the
"purpose" parameter. "icon" designates an image suitable as
forwarded message MUST contain an iconic
representation updated Max-Forwards field with a
value decremented by one (1).

Example:

Max-Forwards: 6

10.28 MIME-Version

See [H19.4.1].

10.29 Organization

The Organization general-header field conveys the name of the caller or callee; "info" describes
organization to which the caller
or callee in general, e.g., through a web page; "card" provides a
business card (e.g., in vCard [30] entity issuing the request or LDIF [31] formats).

Call-Info response
belongs. It MAY also be inserted by proxies at the boundary of an
organization.

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

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

10.30 Priority

The Priority request-header field indicates the urgency of the
request as perceived by the client.

Priority = "Call-Info" "Priority" ":" # ( "<" URI ">" *( ";" info-param) )
info-param priority-value
priority-value = "purpose" "=" ( "icon" "emergency" | "info" "urgent" | "card" "normal"
| token ) "non-urgent" | generic-param

Example:

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

6.15 Contact other-priority
other-priority = token

It is RECOMMENDED that the value of "emergency" only be used when

Handley/Schulzrinne/Schooler/Rosenberg [Page 67]

Internet Draft SIP May 29, 2001

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 the values of RFC 2076 [34], with the addition of
"emergency".

10.31 Proxy-Authenticate

The Contact general-header Proxy-Authenticate response-header field can appear in INVITE, OPTIONS, ACK,
and REGISTER requests, and MUST be included as part
of a 407 (Proxy Authentication Required) response. It may also occur
in 1xx, 2xx, 3xx, and 485 responses. In
general, it provides a URL where 401 (Unauthorized) response if the user can be reached for further
communications.

In some request was forked. The field
value consists of a challenge that indicates the cases below, authentication
scheme and parameters applicable to the client uses information from proxy for this Request-URI.

Unlike its usage within HTTP, the
Contact Proxy-Authenticate header field MUST be
passed upstream in Request-URI of future requests. In these
cases, the response to the UAC. In SIP, only UAC's can
authenticate themselves to proxies.

The syntax for this header is defined in [H14.33]. See 19 for further
details on its usage.

A client copies all but SHOULD cache the "method-param" credentials used for a particular proxy
server and "header"
elements of realm for the addr-spec part next request to that server. Credentials
are, in general, valid for a specific value of the Contact header field into the Request-URI of at a
particular proxy server. If a client contacts a proxy server that has
required authentication in the request. It uses past, but the "header" parameters to create
headers client does not have
credentials for the request, replacing any default headers normally used.
Unless particular Request-URI, it MAY attempt to use the
most-recently used credential. The server responds with 401
(Unauthorized) if the client guessed wrong.

This suggested caching behavior is configured motivated by proxies
restricting phone calls to authenticated users. It seems
likely that in most cases, all destinations require the
same password. Note that end-to-end authentication is
likely to be destination-specific.

Handley/Schulzrinne/Schooler/Rosenberg [Page 68]

Internet Draft SIP May 29, 2001

10.32 Proxy-Authorization

The Proxy-Authorization request-header field allows the client to
identify itself (or its user) to use a default proxy which requires
authentication. The Proxy-Authorization field value consists of
credentials containing the authentication information of the user
agent for all
outgoing requests, it then directs the request to proxy and/or realm of the address and
port specified by resource being requested.

Unlike Authorization, the "maddr" and "port" parameters, Proxy-Authorization header field applies
only to the next outbound proxy that demanded authentication using
the
transport protocol given Proxy- Authenticate field. When multiple proxies are used in the "transport" parameter. If "maddr" is a multicast address,
chain, the value of "ttl" Proxy-Authorization header field is used as consumed by the time-to-live
value.

INVITE, OPTIONS and ACK requests: INVITE requests MUST and ACK
requests first
outbound proxy that was expecting to receive credentials. A proxy MAY contain Contact headers indicating
relay the credentials from which
location the client request is originating. The URL in to the Contact
header field next proxy if
that is then used the mechanism by subsequent requests from which the

Handley/Schulzrinne/Schooler/Rosenberg [Page 52]

Internet Draft SIP November 24, 2000

callee. For OPTIONS, Contact provides proxies cooperatively authenticate
a hint where future
SIP requests can be sent or the user can be contacted via
non-SIP means.

This allows the callee to send future requests, such
as BYE, directly to the caller instead given request.

See [H14.34] for a definition of through the syntax, and section 19 for a
series
discussion of proxies. its usage.

10.33 Proxy-Require

The Via Proxy-Require header field is not sufficient
since the desired address may be used to indicate proxy-sensitive
features that of a MUST be supported by the proxy.

INVITE 1xx responses: A UAS sending a provisional response (1xx)
MAY insert If a Contact response header. It has proxy server does
not understand the same
semantics option, it MUST respond by returning status code
420 (Bad Extension) and list those options it does not understand in a 1xx response as a 2xx INVITE response. Note
that CANCEL requests MUSTNOT be sent
the Unsupported header. A UAC SHOULD attempt to that address, but
rather follow retry the same path as request,
without using the original request.

INVITE features listed in the Unsupported header.

See Section 10.35 for more details on the mechanics of this message
and OPTIONS 2xx responses: A user agent server sending a
definitive, positive response (2xx) MUST insert a Contact
response usage example.

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

10.34 Record-Route

The Record-Route header field indicating has the following syntax:

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

Details of its use are described in Section 16.

Handley/Schulzrinne/Schooler/Rosenberg [Page 69]

Internet Draft SIP address under
which it is reachable most directly for future SIP
requests, such as ACK, within the same Call-ID. May 29, 2001

10.35 Require

The Contact
header Require general-header field contains is used by clients to tell user
agent servers about options that the address of client expects the server itself or
that of a proxy, e.g., if to
support in order to properly process the host is behind request. If a firewall.
The value of this Contact header is copied into the
Request-URI of subsequent requests for this call if server does
not understand the
response did option, it MUST respond by returning status code
420 (Bad Extension) and list those options it does not also contain a Record-Route understand in
the Unsupported header. If A UAC SHOULD attempt to retry the
response also contains a Record-Route header field, request,
without using the
address features listed in the Contact header field 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
Unsupported: com.example.billing

This is added as to make sure that the last
item client-server interaction
will proceed without delay when all options are understood
by both sides, and only slow down if options are not
understood (as in the Route header field. See Section 6.35 for
details.

If example above). For a UA supports both UDP well-matched
client-server pair, the interaction proceeds quickly,
saving a round-trip often required by negotiation
mechanisms. In addition, it also removes ambiguity when the
client requires features that the server does not
understand. Some features, such as call handling fields,
are only of interest to end systems.

Proxy and TCP, it SHOULDNOT indicate redirect servers MUST ignore features that are not
understood. If a
transport parameter in particular extension requires that intermediate
devices support it, the URI.

The Contact value SHOULDNOT extension MUST be cached across calls, as
it may not represent tagged in the most desirable location for a
particular destination address.

3xx and 485 responses: 10.33).

10.36 Response-Key

The Contact response-header Response-Key request-header field can be used with by a 3xx or 485 (Ambiguous) response codes to
indicate one or more alternate addresses to try. It can
appear in responses client to BYE, INVITE and OPTIONS methods. The
Contact header field contains URIs giving
request the new locations
or key that the called user names agent SHOULD use to try, or may simply specify additional
transport parameters. A 300 (Multiple Choices), 301 (Moved encrypt the
response with. The syntax is:

Handley/Schulzrinne/Schooler/Rosenberg [Page 53] 70]

Internet Draft SIP November 24, 2000

Permanently), 302 (Moved Temporarily) or 485 (Ambiguous)
response SHOULD contain a Contact field containing URIs May 29, 2001

Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param
key-scheme = token
key-param = generic-param

The "key-scheme" gives the type of
new addresses encryption to be tried. A 301 or 302 response may also
give used for the same location and username
response. Section 18 describes security schemes.

If the client insists that was being tried
but specify additional transport parameters such as a
different the server or multicast address to try or return an encrypted response,
it includes a change of
SIP transport from UDP to TCP or vice versa. The client
copies information from the Contact

Require: org.ietf.sip.encrypt-response

header field into in its request. If the
Request-URI as described above.

4xx, 5xx server cannot encrypt for
whatever reason, it MUST follow normal Require header field
procedures and 6xx responses: return a 420 (Bad Extension) response. If this Require
header field is not present, a server SHOULD still encrypt if it can.

10.37 Retry-After

The Contact Retry-After response-header field can be used with a 4xx, 5xx or 6xx 503 (Service
Unavailable) response to indicate how long the
location where additional information about the error can service is expected to
be found.

Note that the Contact header field MAY also refer unavailable to a different
entity than the one originally called. For example, a SIP call
connected to GSTN gateway may need to deliver requesting client and with a special information
announcement such as "The number you have dialed has been changed."

A Contact 404 (Not Found),
600 (Busy), or 603 (Decline) response header field can contain any suitable URI
indicating where to indicate when the called
party 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 a mailto: (RFC 2368, [32]) URL.

The following parameters are defined. Additional parameters may be
defined in other specifications.

q: The "qvalue" indicates the relative preference among the
locations given. "qvalue" values are decimal numbers from 0
to 1, with higher values indicating higher preference. anticipates being available again. The
default value is 0.5.

action: The "action" parameter is used only when registering
with the REGISTER request. It indicates whether the client
wishes that the server proxy or redirect future requests
intended for the client. If of this parameter is not specified field can
be either an SIP-date or an integer number of seconds (in decimal)
after the action taken depends on server configuration. In its
response, time of the registrar SHOULD response.

An optional comment can be used to indicate additional information
about the mode used. This
parameter is ignored for other requests.

expires: The "expires" time of callback. An optional "duration" parameter
indicates how long the URI is
valid. The parameter is either a number indicating seconds
or a quoted string containing a SIP-date. called party will be reachable starting at the
initial time of availability. If this no duration parameter is not provided, the value of the Expires header field
determines how long given, the URI
service is valid. Implementations MAY
treat values larger than 2**32-1 (4294967295 seconds or 136
years) as equivalent assumed to 2**32-1.

Handley/Schulzrinne/Schooler/Rosenberg [Page 54]

Internet Draft SIP November 24, 2000

Contact be available indefinitely.

Retry-After = ( "Contact" | "m" ) "Retry-After" ":"
("*" | (1# (( name-addr ( SIP-date | addr-spec delta-seconds )
[ comment ] *( ";" contact-params retry-param ) )))

name-addr = [ display-name ] "<" addr-spec ">"
addr-spec = SIP-URL | URI
display-name = *token | quoted-string

contact-extension = generic-param
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )

Even if the "display-name" is empty,

Examples of its use are

Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in 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

Handley/Schulzrinne/Schooler/Rosenberg [Page 71]

Internet Draft SIP May 29, 2001

Retry-After: 120

In the "name-addr" form MUST be
used if third example, the "addr-spec" contains a comma, semicolon or question mark.
Note that there may or may not be LWS between callee is reachable for one hour starting
at 21:00 GMT. In the display-name and last example, the "<". delay is 2 minutes.

10.38 Route

The Contact Route header field fulfills functionality similar to has the Location header field following syntax:

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

Details of its use are described in HTTP. However, Section 16.

10.39 Server

The Server response-header field contains information about the HTTP header
only allows one address, unquoted. Since URIs can contain
commas and semicolons as reserved characters, they can be
mistaken
software used by the user agent server to handle the request. The
syntax for this field is defined in [H14.38].

10.40 Subject

This header field provides a summary or parameter delimiters, respectively.
The current syntax corresponds indicates the nature of the
call, allowing call filtering without having to that for parse the To and From
header, which also allows session
description. (Note that the session description does not have to use 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

6.16 Content-Disposition

Content-Disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-param )
disposition-type
the same subject indication as the invitation.)

Subject = "render" | "session" | "icon" ( "Subject" | "alert" "s" ) ":" TEXT-UTF8-TRIM

Example:

Subject: Tune in - they are talking about your work!

10.41 Supported

The Supported general-header field enumerates all the capabilities of
the client or server. This header field SHOULD be included in all
requests (except ACK) and in all responses.

Handley/Schulzrinne/Schooler/Rosenberg [Page 55] 72]

Internet Draft SIP November 24, 2000

| disp-extension-token
disposition-param May 29, 2001

Including the header field in all responses greatly
simplifies the use of extensions for call control in
subsequent transactions with the same server.

Syntax:

Supported = "handling" "=" ( "optional" | "required" "Supported" | other-handling "k" )
| generic-param
other-handling = token
disp-extension-token = token ":" 1#option-tag

10.42 Timestamp

The Content-Disposition header Timestamp general-header field describes how when the message body
or, in client sent the case of multipart messages, a message body part is
request to be
interpreted by the UAC or UAS. server. The SIP header extends client uses the MIME
Content-Type (RFC 1806 [33]).

The current time value "session" indicates that at the body part describes
time of transmission, i.e., each retransmission of a session,
for either calls or early (pre-call) media. request is
likely to have a different timestamp value.

The value "render"
indicates that the body part should be displayed or otherwise
rendered to the user. For backward-compatibility, if of the Content-
Disposition header timestamp is not missing, bodies of Content-Type
application/sdp imply significance only to the disposition "session", while other content
types imply "render". client and
it MAY use any timescale. The disposition type "icon" indicates that the body part contains an
image suitable as an iconic representation of server MUST echo the caller or callee.
The exact same value "alert" indicates that the body part contains information,
such as an audio clip, that should be rendered instead of ring tone.

The handling parameter, handling-parm, describes how the UAS should
react
in all provisional and final responses and MAY, if it receives has accurate
information about this, add a message body whose content type or disposition
type it does not understand. If floating point number indicating the parameter
number of seconds that have elapsed since it has received the value
"optional",
request. The timestamp is used by the UAS MUST ignore client to compute the message body; if round-
trip time to the server so that it has can adjust the timeout value
"required", for
retransmissions.

Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ]

Note that there MUST NOT be any LWS between a DIGIT and the UAS decimal
point.

10.43 To

The To general-header field specifies the "logical" recipient of the
request.

To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
*( ";" to-param )
to-param = tag-param | generic-param

Requests and responses MUST return 415 (Unsupported Media Type). If contain a To general-header field,

Handley/Schulzrinne/Schooler/Rosenberg [Page 73]

Internet Draft SIP May 29, 2001

indicating the
handling parameter is missing, desired recipient of the value "required" request. The optional
"display-name" is meant to be assumed.

If this rendered by a human-user interface. The
UAS or redirect server copies the To header field is missing, the MIME type determines the default
content disposition. into its response,
and MUST add a "tag" parameter.

If there was more than one Via header field, the request
was handled by at least one proxy server. Since the
receiver cannot know whether any of the proxy servers
forked the request, it is none, "render" is assumed.

6.17 Content-Encoding

Content-Encoding = ( "Content-Encoding" | "e" ) ":"
1#content-coding safest to assume that they might
have.

The SIP-URL MUST NOT contain 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 Content-Encoding entity-header field is used "tag" parameter serves as a modifier to the
"media-type". When present, its value indicates what additional
content codings have been applied general mechanism to distinguish
multiple instances of a user identified by a single SIP URL. As
proxies can fork requests, the entity-body, same request can reach multiple
instances of a user (mobile and thus what
decoding mechanisms MUST home phones, for example). As each
can respond, there needs to be applied in order a means to obtain distinguish the media-type

Handley/Schulzrinne/Schooler/Rosenberg [Page 56]

Internet Draft SIP November 24, 2000

referenced by responses
from each at the Content-Type caller. The situation also arises with multicast
requests. The tag in the To header field. Content-Encoding is
primarily used to allow a body field serves to distinguish
responses at the UAC. It MUST be compressed without losing placed in the
identity To field of its underlying media type.

If multiple encodings have been applied to an entity, the content
codings
response by user agent, registrar and redirect servers, but MUST NOT
be listed in the order in which they were applied.

All content-coding values are case-insensitive. The Internet Assigned
Numbers Authority (IANA) acts as inserted into responses forwarded upstream by proxies. However,
responses generated locally by a registry proxy, and then sent upstream, MUST
contain a tag.

A UAS or redirect server MUST add a "tag" parameter for content-coding value
tokens. See [H3.5] all final
responses for all transactions within a definition of call leg. All such parameters
have the syntax same value within the same call leg. These servers SHOULD
add the tag for content-coding.

Clients MAY apply content encodings informational responses during the initial INVITE
transaction, but MUST add a tag to informational responses for all
subsequent transactions.

See Section 10.25 for details of the body "tag" parameter. The "tag"
parameter in requests. If the
server To headers is ignored when matching responses to
requests that did not capable of decoding the body, or does not recognize any
of the content-coding values, it MUST send contain a 415 "Unsupported Media
Type" response, listing acceptable encodings "tag" in the Accept-Encoding their To header. A server MAY apply content encodings to

Section 15 describes when the bodies "tag" parameter MUST appear in
responses. The server
subsequent requests. Note that if a request already contained a tag,
this tag MUST only use encodings listed be mirrored in the Accept-
Encoding response; a new tag MUST NOT be
inserted.

Section 10.25 describes how To and From header in the request.

6.18 Content-Language

See [H14.12].

6.19 Content-Length

The Content-Length entity-header field indicates the size of fields are compared
for the
message-body, in decimal number purpose of octets, sent matching requests to the recipient.

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

An example is

Content-Length: 3495

Applications call legs.

Handley/Schulzrinne/Schooler/Rosenberg [Page 74]

Internet Draft SIP May 29, 2001

UAS SHOULD use this field to indicate accept requests even if they do not recognize the size of URI
scheme (e.g., a tel: URI) or if the
message-body To header does not address the
user. Only Request-URI that do not match the recipient should cause
requests to be transferred, regardless of rejected.

Even if the media type of "display-name" is empty, the
entity. (The size of "name-addr" form MUST be
used if the message-body does "addr-spec" contains a comma, question mark, or
semicolon. Note that LWS is common, but not include mandatory between the CRLF
separating headers
display-name and body.) Any Content-Length greater than or
equal 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 zero is identify a valid value. If no body is present call leg.
The distinction between call and call leg matters in calls
with multiple responses from a message,
then forked request. The "tag" is
added to the Content-Length To header field MUST be set in the response to zero. If a
server receives a datagram request without Content-Length, it MUST
assume that allow
forking of future requests for the request encompasses same call by proxies,
while addressing only one of the remainder possibly several
responding user agent servers. It also allows several
instances of the packet. If a
server receives a datagram request with callee to send requests that can be
distinguished.

10.44 Unsupported

The Unsupported response-header field lists the features not
supported by the server. See Section 10.35 for a Content-Length, but 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 the request. The syntax and semantics
are defined in [H14.43].

10.46 Via

Handley/Schulzrinne/Schooler/Rosenberg [Page 57] 75]

Internet Draft SIP November 24, 2000

value differs from May 29, 2001

The Via field indicates the size of path taken by the body sent request so far. This
prevents request looping and ensures replies take the same path as
the requests, which assists in firewall traversal and other unusual
routing situations.

10.46.1 Requests

The client originating the request, request MUST insert into the
server SHOULD return a 400 (Bad Request) response.

If a response does not contain request a Content-Length, Via
field containing the client assumes
that it encompasses transport protocol used to send the remainder of message, the datagram packet
client's host name or network address and, if not the data
until the stream connection is closed, as applicable. Section 8
describes how to determine the length of default port
number, the message body.

The ability port number at which it wishes to omit Content-Length simplifies the creation
of cgi-like scripts that dynamically generate receive responses.

6.20 Content-Type

The Content-Type entity-header field indicates
(Note that this port number can differ from the media type UDP source port
number of the
message-body sent to the recipient. The "media-type" element is
defined in [H3.7]. The Content-Type header field request.) A fully-qualified domain name is ignored if RECOMMENDED.
Each subsequent proxy server that sends the
message body is empty.

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

6.21 CSeq

Clients request onwards MUST add the CSeq (command sequence) general-header
its own additional Via field to
every request. before any existing Via fields. A CSeq header field in proxy
that receives a request contains the request
method redirection (3xx) response and a single decimal sequence number chosen by the requesting
client, unique within a single call leg. The sequence number then searches
recursively, MUST be
expressible use the same Via headers as a 32-bit unsigned integer. The initial value of on the
sequence number is arbitrary, but MUST be less than 2**31.
Consecutive requests original proxied
request.

A client that differ in sends a request method, headers or body,
but have the same Call-ID to a multicast address MUST contain strictly monotonically
increasing add the
"maddr" parameter to its Via header field, and contiguous sequence numbers; sequence numbers do not
wrap around. Retransmissions of SHOULD add the same request carry "ttl"
parameter. (In that case, the same
sequence number, but an INVITE with maddr parameter SHOULD contain the
destination multicast address, although under exceptional
circumstances it MAY contain a different message body or
different header fields (a "re-invitation") acquires unicast address.) If a new, higher
sequence number. A server MUST echo receives
a request which contained an "maddr" parameter in the CSeq value from topmost Via
field, it SHOULD send the request response to the address listed in its response. If the Method value
"maddr" parameter.

Loop detection is missing described in Section 17.3.1.

10.46.2 Receiver-tagged Via Header Fields

A proxy or UAS receiving a request SHOULD check the received CSeq first Via header field, the server fills
field to ensure that it in appropriately.

Handley/Schulzrinne/Schooler/Rosenberg [Page 58]

Internet Draft SIP November 24, 2000

The ACK and CANCEL requests MUST contain contains the same CSeq value sender's correct network
address, as the
INVITE request seen from that it refers to, while proxy. If the Via header contains a BYE request cancelling domain
name or if it contains an
invitation MUST have a higher sequence number. A BYE request with IP address that differs from the packet
source address, the proxy or UAS SHOULD add a
CSeq "received" attribute to
that is Via header field.

A multi-homed host may not higher should cause a 400 response be able to insert a network
address into the Via header field that can be generated.

A user agent server MUST remember reached by
the highest sequence number next hop, for any
INVITE request with example because if one of the same Call-ID value. networks is
private. The server MUST respond
to, and then discard, any INVITE request with a lower sequence
number.

All requests spawned in a parallel search have the same CSeq value as
the request triggering address placed into the parallel search.

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

Strictly speaking, CSeq Via header fields are needed for any
SIP request may differ
from the interface actually used, as that can be cancelled interface is
selected only at packet sending time by the IP layer.
Similarly, a BYE or CANCEL request or where traversing a client can issue several requests for network address
translator (NAT) will also cause the same Call-ID in close succession. Without a sequence
number, sending address to

Handley/Schulzrinne/Schooler/Rosenberg [Page 76]

Internet Draft SIP May 29, 2001

differ from the response address seen by the next hop. The mechanism
described here is unlikely to an INVITE could be mistaken sufficient, however, for the
response
allowing packets to traverse a NAT in the cancellation (BYE or CANCEL). Also, if reverse
direction.

An example is:

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
Via: SIP/2.0/UDP 128.59.16.1:5060 ;received=128.59.19.3

In this example, the message originated from a multi-homed host with
two addresses, 128.59.16.1 and 128.59.19.3. The sender guessed wrong
as to which network duplicates packets or if an ACK is delayed until interface would be used. Erlang.bell-
telephone.com noticed the server has sent an additional response, mismatch, and added a parameter to the client
could interpret an old response as
previous hop's Via header field, containing the response to a re-
invitation issued shortly thereafter. Using CSeq also makes
it easy for address that the server to distinguish different versions of
an invitation, without comparing
packet actually came from.

10.46.3 Receiving Responses

Via header fields in responses received are processed by a proxy or
UAC according to the message body. following rules:

1. The Method value allows first Via header field should indicate the proxy or
client to distinguish the response to an
INVITE request from that of a CANCEL processing this response. CANCEL requests can be
generated Specifically, the sent-by
value should equal the value inserted by proxies; if they were to increase the sequence number,
it might conflict with a later request issued proxy or UAC.
The recevied parameter MUST NOT be used by a proxy or UAC
to determine if the user agent response is for
the same call.

With a length of 32 bits, a server could generate, within a single
call, one request a second for about 136 years before needing it sent. If
the sent-by value is not equal to wrap
around. The initial the value of inserted by the sequence number
proxy or UAC, discard the message. Otherwise, remove this
Via field.

2. If there is chosen so that
subsequent requests within no second Via header field, this response is
destined for this client. Otherwise, use this Via field as
the same call will not wrap around. destination, as described in Section 10.46.5.

10.46.4 Generating Responses

A
non-zero initial value allows to use UAS, proxy or redirect that server that generates a time-based initial sequence
number, if response copies
the client desires. A client could, for example, choose Via header fields from the 31 most significant bits of a 32-bit second clock request into the response, without
changing their order, and uses the top (first) Via element as an initial
sequence number.

Forked requests MUST have the same CSeq
destination, as there would be ambiguity described in the next section.

10.46.5 Sending Responses

Given a destination described by a Via header field, the response is

Handley/Schulzrinne/Schooler/Rosenberg [Page 59] 77]

Internet Draft SIP November 24, 2000

otherwise between these forked requests and later BYE issued by May 29, 2001

sent according to the
client user agent.

Example:

CSeq: 4711 INVITE

6.22 Date

Date following rules:

o If the "sent-protocol" is a general-header field. Its syntax is:

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

See [H14.18] for a definition of rfc1123-date. Note that unlike
HTTP/1.1, SIP only supports reliable transport protocol such
as TCP, TLS or SCTP, send the most recent RFC 1123 [34] formatting
for dates. As in [H3.3], SIP restricts response using the timezone in SIP-date existing TCP
connection to
"GMT", while RFC 1123 allows any timezone.

The consistent use of GMT between Date, Expires and Retry-
After headers allows implementation of simple clients that
do not have a notion the source of absolute time. Note that rfc1123-
date the original request. If no
connection is case-sensitive.

The Date header field reflects open, open a connection to the time when IP address in the request
received parameter, if present using the port in the sent-by
value, or response port 5060 if none is first sent. Thus, retransmissions have the same Date header field
value as present. If the original.

Registrars MUST include this header in REGISTER responses connection
attempt fails, or if they use
absolute expiration times and there was no received parameter, the
server SHOULD include it for all responses.

The Date header field can be used by simple end systems
without attempt to open a battery-backed clock connection to acquire the address in
the sent-by value, which may be a domain name. To do this, it
constructs a notion SIP URL of
current time. However, the form "sip:<sent-
by>;transport=<sent-protocol>" and then uses the procedures
defined in its GMT-form, it requires clients [35] to know their offset from GMT.

6.23 Encryption

The Encryption general-header field specifies that determine the content has
been encrypted. Section 13 describes IP address and port to open
the overall SIP security
architecture connection and algorithms. This send the response to.

o Otherwise, if the Via header field is intended for end-

Handley/Schulzrinne/Schooler/Rosenberg [Page 60]

Internet Draft SIP November 24, 2000

to-end encryption of requests and responses. Requests are encrypted
based on contains a "maddr"
parameter, forward the public key belonging response to the entity named address listed there,
using the port indicated in "sent-by", or port 5060 if none is
present. If the To
header field. Responses are encrypted based on address is a multicast address, the public key
conveyed response
SHOULD be sent using the TTL indicated in the Response-Key header field. Note "ttl" parameter,
or with a TTL of 1 if that the public keys
themselves may parameter is not be used for present.

o Otherwise, if it is a receiver-tagged field (Section 10.46.2),
send the encryption. This depends on response to the
particular algorithms used.

For any encrypted message, at least address in the message body and possibly
other message header fields are encrypted. An application receiving a
request "received" parameter,
using the port indicated in the "sent-by" value, or response containing using port
5060 if none is specified explicitly. If this fails, e.g.,
elicits an Encryption header field decrypts ICMP "port unreachable" response, send the body and then concatenates response
to the plaintext address in the "sent-by" parameter. The address to send
to is determined by constructing a SIP URL of the request line form
"sip:<sent-by>", and
headers of then using the original message. Message headers DNS procedures defined in
[35] to send the decrypted
part completely replace those with response.

o Otherwise, if it is not receiver-tagged, send the same field name in response to
the
plaintext part. (Note: If only address indicated by the body of "sent-by" value.

Note that the message response to an unreliable datagram request is not
returned to be
encrypted, the body has to be prefixed with CRLF to allow proper
concatenation.) Note that port from which the request method and Request-URI cannot
be encrypted.

Encryption only provides privacy; came, but it is always
returned to the recipient has no
guarantee source IP that that the request or response came from the party
listed from.

10.46.6 Syntax

The format for a Via header field is shown in Fig. 9. The "maddr"
parameter, designating the From message header, only that multicast address, and the sender
used "ttl"
parameter, designating the recipient's public key. However, proxies will not
be able to modify time-to-live (TTL) value, are included
only if the request or response.

Encryption was sent via multicast. The "received" parameter
is added only for receiver-added Via fields (Section 10.46.2).

Handley/Schulzrinne/Schooler/Rosenberg [Page 78]

Internet Draft SIP May 29, 2001

Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by
*( ";" via-params ) [ comment ] )
via-params = via-hidden | via-ttl | via-maddr
| via-received | via-branch
via-hidden = "hidden"
via-ttl = "ttl" "=" ttl
via-maddr = "maddr" "=" maddr
via-received = "received" "=" host
via-branch = "branch" "=" token
sent-protocol = protocol-name "/" protocol-version "/" transport
protocol-name = "SIP" | token
protocol-version = token
transport = "UDP" | "TCP" | token
sent-by = "Encryption" ( host [ ":" encryption-scheme 1*SP
#encryption-params
encryption-scheme port ] ) | ( concealed-host )
concealed-host = token
encryption-params
ttl = generic-param 1*3DIGIT ; 0 to 255

Figure 9: Syntax of Via header field

The "branch" parameter is included by every proxy. The token indicates the form MUST be
unique for each distinct request. The precise format of encryption used; it the token is
described in Section 13.

The example in Figure 9 shows a message encrypted
implementation-defined. In order to be able to both detect loops and
associate responses with ASCII-armored
PGP that was generated the corresponding request, the parameter
SHOULD consist of two parts separable by applying "pgp -ea" to the payload to implementation. One
part, used for loop detection (Section 17.3.1), MAY be
encrypted.

Figure 9: PGP Encryption Example

Since proxies can base their forwarding decision on any combination computed as a
cryptographic hash of SIP the To, From, Call-ID header fields, there is no guarantee that an encrypted the
Request-URI of the request
"hiding" received (before translation) and the
sequence number from the CSeq header field. The hash SHOULD also
include any other fields will reach the same destination as an

Handley/Schulzrinne/Schooler/Rosenberg [Page 61]

Internet Draft SIP November 24, 2000

INVITE sip:watson@boston.bell-telephone.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5
From: <sip:a.g.bell@bell-telephone.com>
To: T. A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@worcester.bell-telephone.com
Cseq: 1 INVITE
Content-Length: 829
Encryption: PGP version=2.6.2,encoding=ascii

hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red
h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs
ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR
RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA
zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu
X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6
IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/
GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E
WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed
wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO
z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+
6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2
z8X9N4MhMyXEVuC9rt8/AUhmVQ==
=bOW+

otherwise identical un-encrypted request.

6.24 Error-Info

The Error-Info response header provides a pointer proxy uses to additional
information about make a routing decision on
the error status response. request. This header field is
only contained in 3xx, 4xx, 5xx and 6xx responses.

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

6.25 Expires

The Expires entity-header field gives the date and time after which to ensure that if the message content expires.

This header field request is currently defined only for routed back to
the REGISTER proxy, and
INVITE methods. For REGISTER, one of those fields changes, it is treated as a request
spiral, and response-header
field. In not a REGISTER request, the client indicates how long it wishes loop. The algorithm used to compute the registration hash is
implementation-dependent, but MD5 [36], expressed in hexadecimal, is
a reasonable choice. (Note that base64 is not permissible for a
token.) The other part, used for matching responses to be valid. In requests, is a
globally unique function of the response, branch taken, for example, a hash of
a sequence number, local IP address and request-URI of the server indicates request
sent on the earliest expiration time of all registrations. branch.

For example: 7a83e5750418bce23d5106b4c06cc632.1

The server MAY "branch" parameter MUST depend on the incoming

Handley/Schulzrinne/Schooler/Rosenberg [Page 62] 79]

Internet Draft SIP November 24, 2000

choose a shorter time interval than that requested by the client, but
SHOULDNOT choose a longer one. If May 29, 2001

request-URI, or any other headers used for routing, to
distinguish looped requests from requests whose request-URI
(or whatever headers are used for routing) is changed and
which then reach a registration updates an existing
registration, server visited earlier.

CANCEL and ACK requests MUST have the Expires same branch value of as the most recent registration is
used, even if it is shorter than
corresponding request they cancel or acknowledge. When a response
arrives at the earlier registration.

For INVITE requests, proxy it can use the branch value to figure out which
branch the response corresponds to.

Via: SIP/2.0/UDP first.example.com:4000;ttl=16
;maddr=224.2.0.1 ;branch=a7c6a8dlze.1 (Acme server)
Via: SIP/2.0/UDP adk8

10.47 Warning

The Warning response-header field is used to carry additional
information about the status of a request response. Warning headers are sent
with responses and response-header field. In a
request, have the caller can limit following format:

Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the validity name or pseudonym of an invitation, for
example, if a client wants to limit the time duration of a search or
a conference invitation. server adding
; the Warning header, for use in debugging
warn-text = quoted-string
pseudonym = token

A user interface response MAY take this as carry more than one Warning header.

The "warn-text" should be in a hint natural language that is most likely
to be intelligible to
leave the invitation window on the screen even if the human user is not
currently at receiving the workstation. response. This also limits
decision can be based on any available knowledge, such as the duration
location of a
search. If the request expires before cache or user, the search completes, Accept-Language field in a
request, or the proxy
returns Content-Language field in a 408 (Request Timeout) status. In response. The default
language is i-default [37].

Any server MAY add Warning headers to a 302 (Moved Temporarily)
response, response. Proxy servers MUST
place additional Warning headers before any Authorization headers.
Within that constraint, Warning headers MUST be added after any
existing Warning headers not covered by a signature. A proxy server can advise the client of

Handley/Schulzrinne/Schooler/Rosenberg [Page 80]

Internet Draft SIP May 29, 2001

MUST NOT delete any Warning header field that it received with a
response.

When multiple Warning headers are attached to a response, the maximal duration user
agent SHOULD display as many of them as possible, in the redirection.

Note order that
they appear in the expiration time does response. If it is not affect the duration possible to display all of
the
actual session that may result from the invitation. Session
description protocols may offer warnings, the ability to express time limits on user agent first displays warnings that appear
early in the session duration, however. response.

The value warn-code consists of this field can be either a SIP-date or an integer number three digits. A first digit of seconds (in decimal), measured from the receipt "3"
indicates warnings specific to SIP.

This is a list of the request.
The latter approach is preferable for short durations, as it does not
depend on clients currently-defined "warn-code"s, each with a
recommended warn-text in English, and servers sharing a synchronized clock.
Implementations MAY treat values larger than 2**32-1 (4294967295 or
136 years) as equivalent to 2**32-1.

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

Two examples description of its use meaning.
Note that these warnings describe failures induced by the session
description.

Warnings 300 through 329 are

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

6.26 From

Requests and responses MUST contain a From general-header field, reserved for indicating problems with
keywords in the initiator of session description, 330 through 339 are warnings
related to basic network services requested in the request. (Note that this may be
different from session
description, 370 through 379 are warnings related to quantitative QoS
parameters requested in the initiator session description, and 390 through 399
are miscellaneous warnings that do not fall into one of the call leg. Requests sent by above
categories.

300 Incompatible network protocol: One or more network protocols
contained in the
callee to session description are not available.

301 Incompatible network address formats: One or more network
address formats contained in the caller use session description are
not available.

302 Incompatible transport protocol: One or more transport
protocols described in the callee's address session description are not
available.

303 Incompatible bandwidth units: One or more bandwidth
measurement units contained in the From header
field.) The From field MAY contain session description were
not understood.

304 Media type not available: One or more media types contained
in the "tag" parameter. The server
copies session description are not available.

305 Incompatible media format: One or more media formats
contained in the From header field from session description are not available.

306 Attribute not understood: One or more of the request to media
attributes in the response. The session description are not supported.

Handley/Schulzrinne/Schooler/Rosenberg [Page 63] 81]

Internet Draft SIP November 24, 2000

optional "display-name" is meant to be rendered by a human-user
interface. May 29, 2001

307 Session description parameter not understood: A system SHOULD use the display name "Anonymous" if parameter
other than those listed above was not understood.

330 Multicast not available: The site where the
identity of user is located
does not support multicast.

331 Unicast not available: The site where the client user is located
does not support unicast communication (usually due to remain hidden. the
presence of a firewall).

370 Insufficient bandwidth: The SIP-URL MUSTNOT contain bandwidth specified in the "transport-param", "maddr-param",
"ttl-param",
session description or "headers" elements. A server defined by the media exceeds that receives
known to be available.

399 Miscellaneous warning: The warning text can include
arbitrary information to be presented to a SIP-URL
with these elements ignores them.

Even if human user, or
logged. A system receiving this warning MUST NOT take any
automated action.

1xx and 2xx have been taken by HTTP/1.1.

If the "display-name" warning is empty, caused by the "name-addr" form MUST be
used if session description, the "addr-spec" contains status
response SHOULD include a comma, question mark, or
semicolon. Syntax issues are discussed in Section 6.5.

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
From: Anonymous <sip:c8oqz84zk7z@privacy.org>

The "tag" MAY appear session description similar to that
included in OPTIONS responses indicating the From field capabilities of a request. It MUST the UAS.

Additional "warn-code"s, as in the example below, can be
present when it is possible that two instances of a user sharing a
SIP defined
through IANA.

Examples:

Warning: 307 isi.edu "Session parameter 'foo' not understood"
Warning: 301 isi.edu "Incompatible network address can make call invitations with the same Call-ID. type 'E.164'"

10.48 WWW-Authenticate

The "tag" value WWW-Authenticate response-header field MUST be globally unique and cryptographically random
with at least 32 bits of randomness. included in 401
(Unauthorized) response messages. The UA SHOULD use different
tags for From and To header fields, but use the same pair field value consists of tags at
least within one challenge that indicates the same Call-ID. It is RECOMMENDED authentication scheme(s) and
parameters applicable to maintain the same
tag pair across calls Request-URI. See [H14.47] for a
definition of the syntax, and instances Section 19 for an overview of usage.

The content of the UA application.

Maintaining "realm" parameter SHOULD be displayed to the same tag pair allow restarting of a user.
A user agent within interrupting existing calls. Using different
tag values for From and To header fields simplifies users
calling themselves.

For SHOULD cache the purpose authorization credentials for a given
value of identifying call legs, two From or To header
fields are equal if the destination (To header) and only if: "realm" and attempt to re-

Handley/Schulzrinne/Schooler/Rosenberg [Page 64] 82]

Internet Draft SIP November 24, 2000

o The addr-spec component is equal, according to May 29, 2001

use these values on the rules in
Section 2.1.

o Any "tag" next request for that destination.

11 Status Code Definitions

The response codes are consistent with, and "generic-param" parameters extend, HTTP/1.1 response
codes. Not all HTTP/1.1 response codes are equal, compared
according to the case-sensitivity rules in Section 6. Only
parameters appropriate, and only
those that appear in both header fields are compared.

Call-ID, To and From appropriate are needed given here. Other HTTP/1.1 response
codes SHOULD NOT be used. Response codes not defined by HTTP/1.1 have
codes x80 upwards to identify a call leg.
The distinction between call and call leg matters in calls avoid clashes with multiple responses to future HTTP response codes.
Also, SIP defines a forked request. new class, 6xx. The format default behavior for unknown
response codes is
similar to the equivalent RFC 822 [26] header, but with a
URI instead given for each category of just an email address.

6.27 In-Reply-To

The In-Reply-To request header field enumerates the call-IDs codes.

11.1 Informational 1xx

Informational responses indicate that
this call references or returns.

This allows automatic call distribution systems to route
return calls to the originator of server or proxy contacted
is performing some further action and does not yet have a definitive
response. The client SHOULD wait for a further response from the first call
server, and allows
callees the server SHOULD send such a response without further
prompting. A server SHOULD send a 1xx response if it expects to filter calls, so take
more than 200 ms to obtain a final response. A server MAY issue zero
or more 1xx responses, with no restriction on their ordering or
uniqueness. Note that only calls 1xx responses are not transmitted reliably,
that return
calls is, they have originated will be accepted. This field is do not a substitute for request authentication.

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

Example:

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

6.28 Max-Forwards

The Max-Forwards request-header field may be used with any SIP method cause the client to limit send an ACK. Servers are
free to retransmit informational responses and clients can inquire
about the number current state of proxies or gateways that can forward call processing by re-sending the
request to request.

Informational (1xx) responses other than 100 (Trying) MAY contain
message bodies, including session descriptions. If a 1xx response
contains a session description, a UAC SHOULD cease generating local
ringback tone. Session descriptions in 1xx responses are interpreted
in the next downstream server. This can also be useful when same manner as those in 2xx responses. In particular, the client is attempting to trace
session description MUST be formatted in such a request chain which appears to way that it would be
failing or looping
valid in mid-chain.

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

Handley/Schulzrinne/Schooler/Rosenberg [Page 65]

Internet Draft SIP November 24, 2000

The Max-Forwards value is a decimal integer indicating 2xx response. Thus, the remaining
number of times this request message is allowed to be forwarded.

Each proxy or gateway recipient of a request containing UAS can only include a Max-
Forwards header field MUST check and update session
description in its value prior to
forwarding provisional response if the request. UAC has included one
in an earlier INVITE. (SIP extensions may specify additional
circumstances where session descriptions may be included.) If the received value is zero (0), the
recipient MUSTNOT forward the request and returns 483 (Too many
hops). Instead, a server MAY act as later
provisional response or 2xx contains a final recipient for OPTIONS
requests. It different session description,
this new description is RECOMMENDED that the server include Supported, Server
and Allow header fields in treated as if it were the response.

If original response
to the received Max-Forwards value is greater than zero, then session description in the
forwarded message MUST contain an updated Max-Forwards field with a
value decremented by one (1).

Example:

Max-Forwards: 6

6.29 MIME-Version

See [H19.4.1].

6.30 Organization INVITE.

The Organization general-header field conveys UAS can remove the name of media stream by setting the
organization port number to which the entity issuing the request or
zero in a subsequent session description contained in a provisional
response
belongs. It MAY also be inserted by proxies at the boundary of an
organization. and thus restore normal ringback behavior. The field MAY be used UAS cannot
add media streams beyond those offered by client software to filter calls.

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

6.31 Priority

The Priority request-header field indicates the urgency of UAC in the
request INVITE. A
provisional response without a session description has no effect on
any early media that have already been set up.

The media streams are assumed to be bidirectional unless marked as perceived by the client.

Priority = "Priority" ":" priority-value

Handley/Schulzrinne/Schooler/Rosenberg [Page 66] 83]

Internet Draft SIP November 24, 2000

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

It is RECOMMENDED that the value of "emergency" only be used when
life, limb May 29, 2001

send-only or property are receive-only. For SDP, this is described in imminent danger.

Examples:

Subject: A tornado Section B.
Client behavior when receiving several different session descriptions
from different branches is heading our way!
Priority: emergency

Subject: Weekend plans
Priority: non-urgent

These are the values of RFC 2076 [35], with the addition of
"emergency".

6.32 Proxy-Authenticate

The Proxy-Authenticate response-header field MUST be included as part undefined.

11.1.1 100 Trying

Some unspecified action is being taken on behalf of this call (e.g.,
a 407 (Proxy Authentication Required) response. It may also occur
in a 401 (Unauthorized) response if database is being consulted), but the request was forked. user has not yet been
located.

11.1.2 180 Ringing

The
field value consists of called user agent has located a challenge that indicates possible location where the authentication
scheme user
has registered recently and parameters applicable is trying to alert the user.

11.1.3 181 Call Is Being Forwarded

A proxy for server MAY use this Request-URI.

Unlike its usage within HTTP, status code to indicate that the Proxy-Authenticate header MUST be
passed upstream in call is
being forwarded to a different set of destinations.

11.1.4 182 Queued

The called party is temporarily unavailable, but the response callee has
decided to queue the UAC. In SIP, only UAC's can
authenticate themselves to proxies. call rather than reject it. When the callee
becomes available, it will return the appropriate final status
response. The syntax for this header is defined in [H14.33]. See 14 for reason phrase MAY give further details on its usage.

A client SHOULD cache about the credentials used for a particular proxy
server and realm for status
of the next request call, e.g., "5 calls queued; expected waiting time is 15
minutes". The server MAY issue several 182 responses to that server. Credentials
are, in general, valid for a specific value update the
caller about the status of the Request-URI at a
particular proxy server. If a client contacts a proxy server that has
required authentication in queued call.

11.1.5 183 Session Progress

The 183 (Session Progress) response is used to convey information
about the past, but progress of the client does call which is not have
credentials for the particular Request-URI, it otherwise classified. The
Reason-Phrase MAY attempt be used to use convey more details about the
most-recently used credential. call
progress.

11.2 Successful 2xx

The server responds request was successful and MUST terminate a search.

11.2.1 200 OK

The request has succeeded. The information returned with 401
(Unauthorized) if the client guessed wrong. response
depends on the method used in the request, for example:

BYE: The call has been terminated. The message body is empty.

Handley/Schulzrinne/Schooler/Rosenberg [Page 67] 84]

Internet Draft SIP November 24, 2000

This suggested caching behavior May 29, 2001

CANCEL: The search has been cancelled. The message body is motivated by proxies
restricting phone calls
empty.

INVITE: The callee has agreed to authenticated users. It seems
likely that in most cases, all destinations require participate; the
same password. Note that end-to-end authentication is
likely to be destination-specific.

6.33 Proxy-Authorization message body
indicates the callee's capabilities.

OPTIONS: The Proxy-Authorization request-header field allows callee has agreed to share its capabilities,
included in the message body.

REGISTER: The registration has succeeded. The client treats the
message body according to
identify itself (or its user) Content-Type.

11.3 Redirection 3xx

3xx responses give information about the user's new location, or
about alternative services that might be able to a proxy which requires
authentication. The Proxy-Authorization field value consists of
credentials containing satisfy the authentication information of call.
They SHOULD terminate an existing search, and MAY cause the initiator
to begin a new search if appropriate.

To avoid forwarding loops, a user agent for the client or proxy and/or realm of MUST check
whether the resource being requested.

Unlike Authorization, address returned by a redirect server equals an address
tried earlier.

11.3.1 300 Multiple Choices

The address in the Proxy-Authorization header field applies
only request resolved to several choices, each with its
own specific location, and the next outbound proxy that demanded authentication using
the Proxy- Authenticate field. When multiple proxies are used in user (or user agent) can select a
chain, the Proxy-Authorization header field is consumed by the first
outbound proxy that was expecting
preferred communication end point and redirect its request to receive credentials. A proxy MAY
relay the credentials that
location.

The response SHOULD include an entity containing a list of resource
characteristics and location(s) from which the client request to user or user agent can
choose the next proxy one most appropriate, if
that is the mechanism allowed by which the proxies cooperatively authenticate
a given request.

See [H14.34] for a definition of the syntax, and section 14 for a
discussion of its usage.

6.34 Proxy-Require Accept request
header. The Proxy-Require header field entity format is used to indicate proxy-sensitive
features that MUST be supported specified by the proxy. Any Proxy-Require
header field features that are not supported by media type given in the proxy MUST
Content-Type header field. The choices SHOULD also be
negatively acknowledged by listed as
Contact fields (Section 10.14). Unlike HTTP, the proxy to SIP response MAY
contain several Contact fields or a list of addresses in a Contact
field. User agents MAY use the client if not supported.
Proxy servers treat this Contact header field identically to the Require field.

See Section 6.36 value for more details on
automatic redirection or MAY ask the mechanics of this message
and user to confirm a usage example.

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

6.35 Record-Route

6.35.1 Operation

The Record-Route request and choice.
However, this specification does not define any standard for such
automatic selection.

This status response header field is added appropriate if the callee can be
reached at several different locations and the server
cannot or prefers not to a
request by any proxy that insists on being in the path of subsequent request.

11.3.2 301 Moved Permanently

Handley/Schulzrinne/Schooler/Rosenberg [Page 68] 85]

Internet Draft SIP November 24, 2000

requests for May 29, 2001

The user can no longer be found at the same call leg. A proxy SHOULD add it to any request
for robustness, but a request route, once established, persists until address in the end of Request-URI and
the call leg, regardless of whether requesting client SHOULD retry at the Record-Route
header is present in subsequent requests.

The Record-Route new address given by the
Contact header field contains a globally reachable SIP-URI
that identifies the proxy server, including an (Section 10.14). The caller SHOULD update any
local directories, address parameter
(maddr) that identifies its location. Each such proxy server adds books and user location caches with this
new value and redirect future requests to the address(es) listed.

11.3.3 302 Moved Temporarily

The requesting client SHOULD retry the request at the new address(es)
given by the Contact header field (Section 10.14). The Request-URI
of the incoming new request to uses the beginning value of the list.
Requests between both user agents involved Contact header in the call leg, in either
direction, traverse this route.

Some proxies, such as those controlling firewalls or in an
automatic call distribution (ACD) system, need to maintain
call state and thus need to receive any BYE, re-INVITE
response. The new request can take two different forms. In the first
approach, the To, From, Call-ID, and
ACK packets for CSeq header fields in the call. Note that proxy servers have to
add Record-Route headers to each new
request are the same as long as they
want to be "visited" by in the next request for original request, with a new branch
identifier in the call leg. Via header field. Proxies MUST include an maddr parameter in the URI in follow this behavior
and UACs MAY. UAs MAY also use the Record-
Route header, but MUSTNOT include a transport parameter. If Contact information for the
Request-URI did not contain To
header field, as well as a port number and new Call-ID value.

Reusing the server port number
differs from CSeq value allows proxies to avoid forwarding
the default, request to the same destination twice, as a proxy MUST add will
consider it a port number to the
hostport portion retransmission.

The duration of the Request-URI. redirection can be indicated through an Expires
(Section 10.24) header. If it there is important that all requests go to the same host,
server administrators are advised to be careful in
selecting no explicit expiration time, the appropriate name or
address to ensure that
name resolution does indeed resolve to the same host. For
example, a domain name having an SRV record may resolve to
a different network addresses on each attempt. Inclusion
of, say, a TCP transport parameter may prevent a UA that
supports is only UDP but reached valid for this call and MUST NOT be cached for future
calls.

11.3.4 305 Use Proxy

The requested resource MUST be accessed through the proxy inserting given by
the
Record-Route via another proxy from reaching Contact field. The Contact field gives the URI of the proxy. The
recipient is expected to repeat this single request via the proxy.
305 responses MUST only be generated by user agent servers.

11.3.5 380 Alternative Service

The UAS copies call was not successful, but alternative services are possible.
The alternative services are described in the Record-Route request header field unchanged into message body of the
response. (Record-Route is only relevant Formats for 2xx responses such bodies are not defined here, and
responses where the server can expect may be
the subject of future standardization.

11.4 Request Failure 4xx

4xx responses are definite failure responses from a particular
server. The client to SHOULD NOT retry for the same Call-Id, as in 401 (Unauthorized) or 484 (Address Incomplete).)

6.35.2 Construction of Route Header

Once a proxy P inserts a Record-Route header in a request from UA A
to UA B, all subsequent requests from A to B and from B to A visit P.

A UA builds the Route header field for subsequent requests from without
modification (e.g., adding appropriate authorization). However, the
same request to a different server might be successful.

Handley/Schulzrinne/Schooler/Rosenberg [Page 69] 86]

Internet Draft SIP November 24, 2000

Record-Route header fields received in either a response or a
request.

If a UAC finds a Record-Route header in a final response, it copies
it, including all parameters, into Route header fields of all
subsequent requests within the same call leg, reversing the order of
fields, so that the first entry is the server closest May 29, 2001

11.4.1 400 Bad Request

The request could not be understood due to malformed syntax. The
Reason-Phrase SHOULD identify the UAC. If
the syntax problem in more detail,
e.g., "Missing Call-ID header".

11.4.2 401 Unauthorized

The request requires user authentication. This response contained a Contact header field, the is issued by
user agent adds
its content as servers and registrars, while 407 (Proxy Authentication
Required) is used by proxy servers.

11.4.3 402 Payment Required

Reserved for future use.

11.4.4 403 Forbidden

The server understood the last Route header.

If a UAS finds a Record-Route header in a request, it copies the
Record-Route maddr parameters as well as other Record-Route
parameters and any port value, maintaining their ordering, but is refusing to fulfill it.
Authorization will not help, and the
Route header field of future requests issued as a UAC. Since request SHOULD NOT be repeated.

11.4.5 404 Not Found

The server has definitive information that the URIs
contained user does not exist at
the domain specified in the Record-Route header fields are not useful for Request-URI. This status is also returned
if the
reverse request path, domain in the UA fills all other components Request-URI does not match any of the Route
name-addr value with the name-addr value found in domains
handled by the Contact or recipient of the
From header field. request.

11.4.6 405 Method Not Allowed

The latter is used only if there is no Contact
header field. All URI parameters method specified in the Contact or From header field
are copied.

If the request featured a Contact header field, the Contact header
value Request-Line is appended to not allowed for the Route
address identified by the Request-URI. The response MUST include an
Allow header list.

6.35.3 Request Destination

Unless this would cause field containing a loop, any client, including list of valid methods for the UAC, SHOULD
send
indicated address.

11.4.7 406 Not Acceptable

The resource identified by the next request for this call leg is only capable of generating
response entities which have content characteristics not acceptable
according to the first Request-URI accept headers sent in the Route request header field. A client MAY forward the request request.

11.4.8 407 Proxy Authentication Required

This code is similar to a
designated proxy instead, for example, if it lacks DNS resolution
capability. If a client uses 401 (Unauthorized), but indicates that the
client MUST first Route entry to route authenticate itself with the
request, it removes it.

6.35.4 Syntax proxy. The Record-Route proxy MUST
return a Proxy-Authenticate header field has the following syntax:

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

Proxy servers MUST include their address in (section 10.31) containing a "maddr" URL parameter
to ensure that subsequent requests are guaranteed
challenge applicable to reach exactly the same server.

6.35.5 Example proxy for the requested resource. The
client MAY repeat the request with a suitable Proxy-Authorization

Handley/Schulzrinne/Schooler/Rosenberg [Page 70] 87]

Internet Draft SIP November 24, 2000

Example for a request where the proxy servers ieee.org and bell-
telephone.com , in that order, insist on being part of subsequent
request paths:

Record-Route: <sip:a.g.bell@bell-telephone.com;maddr=s.bell-telephone.com>,
<sip:a.bell@ieee.org;maddr=199.172.136.40>

6.36 Require

The Require general-header May 29, 2001

header field (section 10.32). SIP access authentication is used by clients to tell user
agent servers about options that the client expects the server to
support explained
in order to properly process the request. If a server does
not understand the option, it MUST respond by returning status code
420 (Bad Extension) section 18.2 and list those options it does not understand in
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
Unsupported: com.example.billing 19.

This status code is used for applications where access to make sure that the client-server interaction
will proceed without delay when all options are understood
by both sides, and only slow down if options are not
understood (as in the example above). For a well-matched
client-server pair, the interaction proceeds quickly,
saving
communication channel (e.g., a round-trip often required by negotiation
mechanisms. In addition, it also removes ambiguity when telephony gateway) rather than the
client
callee requires features that the authentication.

11.4.9 408 Request Timeout

The server does not
understand. Some features, such as call handling fields,
are only of interest to end systems.

Proxy and redirect servers MUST ignore features that are could not
understood. If produce a particular extension requires that intermediate

Handley/Schulzrinne/Schooler/Rosenberg [Page 71]

Internet Draft SIP November 24, 2000

devices support it, response within a suitable amount of
time, for example, since it could not determine the extension MUST be tagged in location of the Proxy-Require
field as well (see Section 6.34).

6.37 Response-Key
user in time. The Response-Key amount of time may have been indicated in the
Expires request-header field can or may be used set by a client to
request the key that server. The client
MAY repeat the called user agent SHOULD use request without modifications at any later time.

11.4.10 409 Conflict

The request could not be completed due to encrypt a conflict with the current
state of the resource. This response with. The syntax is:

Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param
key-scheme = token
key-param = generic-param is returned if the action
parameter in a REGISTER request conflicts with existing
registrations.

11.4.11 410 Gone

The "key-scheme" gives requested resource is no longer available at the type of encryption server and no
forwarding address is known. This condition is expected to be used for the
response. Section 13 describes security schemes.
considered permanent. If the client insists that the server return an encrypted response,
it includes a

Require: org.ietf.sip.encrypt-response

header field in its request. If does not know, or has no facility
to determine, whether or not the server cannot encrypt for
whatever reason, it MUST follow normal Require header field
procedures and return a 420 (Bad Extension) response. If this Require
header field condition is not present, a server permanent, the status
code 404 (Not Found) SHOULD still encrypt if it can.

6.38 Retry-After

The Retry-After response-header field can be used with a 503 (Service
Unavailable) response instead.

11.4.12 413 Request Entity Too Large

The server is refusing to indicate how long process a request because the service request
entity is expected larger than the server is willing or able to
be unavailable process. The
server MAY close the connection to prevent the requesting client and with a 404 (Not Found),
600 (Busy), or 603 (Decline) response to indicate when from continuing
the called
party anticipates being available again. The value of this field can
be either an SIP-date or an integer number of seconds (in decimal)
after request.

If the time of condition is temporary, the response.

A REGISTER request MAY server SHOULD include this a Retry-
After header field when deleting
registrations with "Contact: * ;expires: 0". The Retry-After value
then indicates when the user might again be reachable. The registrar
MAY then include this information in responses to future calls.

An optional comment can be used to indicate additional information
about the time of callback. An optional "duration" parameter
indicates how long the called party will be reachable starting at the
initial time of availability. If no duration parameter that it is given, temporary and after what
time the

Handley/Schulzrinne/Schooler/Rosenberg [Page 72]

Internet Draft SIP November 24, 2000

service client MAY try again.

11.4.13 414 Request-URI Too Long

The server is assumed refusing 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 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 the third example, service the callee is reachable for one hour starting
at 21:00 GMT. In request because the last example, Request-URI
is longer than the delay server is 2 minutes.

6.39 Route willing to interpret.

11.4.14 415 Unsupported Media Type

Handley/Schulzrinne/Schooler/Rosenberg [Page 88]

Internet Draft SIP May 29, 2001

The Route request-header field determines server is refusing to service the route taken request because the message
body of the request is in a format not supported by the server for
the requested method. The server SHOULD return a
request. Each host removes list of acceptable
formats using the first entry Accept, Accept-Encoding and then proxies Accept-Language header
fields. The client SHOULD retry the
request to request, this time omitting any
bodies not supported by the host listed in that entry, also using it as server.

11.4.15 420 Bad Extension

The server did not understand the
Request-URI. protocol extension specified in a
Proxy-Require (Section 10.33) or Require (Section 10.35) header
field.

11.4.16 480 Temporarily Unavailable

The operation callee's end system was contacted successfully but the callee is described
currently unavailable (e.g., not logged in, logged in more detail in Section
6.35. such a
manner as to preclude communication with the callee or activated the
"do not disturb" feature). The Route header field has response MAY indicate a better time to
call in the following syntax:

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

6.40 Server Retry-After header. The Server response-header field contains information about user could also be available
elsewhere (unbeknownst to this host), thus, this response does not
terminate any searches. The reason phrase SHOULD indicate a more
precise cause as to why the
software used callee is unavailable. This value SHOULD
be setable by the user agent server agent. Status 486 (Busy Here) MAY be used to handle the request. The
syntax
more precisely indicate a particular reason for this field is defined in [H14.38].

6.41 Subject the call failure.

This header field provides status is also returned by a summary or indicates redirect server that recognizes the nature of
user identified by the
call, allowing Request-URI, but does not currently have a
valid forwarding location for that user.

11.4.17 481 Call Leg/Transaction Does Not Exist

This status is returned under three conditions: The server received a
BYE request that does not match any existing call filtering without having to parse leg, the session
description. (Note server
received a CANCEL request that does not match any existing
transaction or the session description server received an INVITE with a To tag that does
not have match the local tag value. (A server simply discards an ACK
referring to use an unknown transaction.) A UAC receiving a 481 to a
request sent for an existing call leg MUST consider that call leg
terminated.

11.4.18 482 Loop Detected

The server received a request with a Via (Section 10.46) path
containing itself.

11.4.19 483 Too Many Hops

Handley/Schulzrinne/Schooler/Rosenberg [Page 73] 89]

Internet Draft SIP November 24, 2000

the same subject indication as the invitation.)

Subject = ( "Subject" | "s" ) ":" TEXT-UTF8-TRIM

Example:

Subject: Tune in - they are talking about your work!

6.42 Supported May 29, 2001

The Supported general-header field enumerates all the capabilities of server received a request that contains a Max-Forwards (Section
10.27) header with the client value zero.

11.4.20 484 Address Incomplete

The server received a request with a To (Section 10.43) address or server. This header field
Request-URI that was incomplete. Additional information SHOULD be included in all
requests (except ACK) and in all responses.

Including
provided.

This status code allows overlapped dialing. With overlapped
dialing, the header field in all responses greatly
simplifies client does not know the use length of extensions the dialing
string. It sends strings of increasing lengths, prompting
the user for call control more input, until it no longer receives a 484
status response.

11.4.21 485 Ambiguous

The callee address provided in
subsequent transactions with the same server.

Syntax:

Supported = ( "Supported" | "k" ) ":" 1#option-tag

6.43 Timestamp request was ambiguous. The Timestamp general-header field describes when
response MAY contain a listing of possible unambiguous addresses in
Contact headers.

Revealing alternatives can infringe on privacy concerns of the client sent user
or the
request organization. It MUST be possible to configure a server to
respond with status 404 (Not Found) or to suppress the server. The value listing of
possible choices if the timestamp is of significance
only request address was ambiguous.

Example response to a request with the client URL lee@example.com :

485 Ambiguous SIP/2.0
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sip:lee.foote@example.com>

Some email and it MAY use any timescale. The server MUST echo voice mail systems provide this
functionality. A status code separate from 3xx is used
since the exact same value and MAY, if semantics are different: for 300, it has accurate information about
this, add a floating point number indicating the number of seconds is assumed
that have elapsed since it has received the request. The timestamp
is used same person or service will be reached by the client to compute the round-trip time to the server so
that it can adjust the timeout value
choices provided. While an automated choice or sequential
search makes sense for retransmissions.

Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
delay = *(DIGIT) [ "." *(DIGIT) ] a 3xx response, user intervention is
required for a 485 response.

11.4.22 486 Busy Here

The callee's end system was contacted successfully but the callee is

Handley/Schulzrinne/Schooler/Rosenberg [Page 74] 90]

Internet Draft SIP November 24, 2000

Note that there MUSTNOT May 29, 2001

currently not willing or able to take additional calls at this end
system. The response MAY indicate a better time to call in the
Retry-After header. The user could also be any LWS between available elsewhere, such
as through a DIGIT and voice mail service, thus, this response does not
terminate any searches. Status 600 (Busy Everywhere) SHOULD be used
if the decimal
point.

6.44 To client knows that no other end system will be able to accept
this call.

11.4.23 487 Request Terminated

The To general-header field specifies request was terminated by a BYE or CANCEL request. This response
is never returned for a CANCEL request itself.

11.4.24 488 Not Acceptable Here

The response has the "logical" recipient of same meaning as 606 (Not Acceptable), but only
applies to the
request.

To = ( "To" | "t" ) ":" ( name-addr | addr-spec )
*( ";" to-param )
to-param = tag-param | generic-param

Requests specific entity addressed by the Request-URI and the
request may succeed elsewhere.

11.5 Server Failure 5xx

5xx responses are failure responses given when a server itself has
erred. They are not definitive failures, and MUST contain NOT terminate a To general-header field,
indicating the desired recipient of
search if other possible locations remain untried.

11.5.1 500 Server Internal Error

The server encountered an unexpected condition that prevented it from
fulfilling the request. The optional
"display-name" is meant to be rendered by a human-user interface. The
UAS or redirect server copies client MAY display the To header field into its response, specific error
condition, and MUST add a "tag" parameter.

If there was more than one Via header field, MAY retry the request
was handled by at least one proxy server. Since the
receiver cannot know whether any of the proxy servers
forked after several seconds.

If the request, it condition is safest to assume that they might
have.

The SIP-URL MUSTNOT contain temporary, 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 to distinguish
multiple instances of a user identified by a single SIP URL. As
proxies can fork requests, MAY indicate when the same request can reach multiple
instances of a user (mobile and home phones, for example). As each
can respond, there needs to be a means to distinguish
client may retry the responses
from each at request using the caller. The situation also arises with multicast
requests. Retry-After header.

11.5.2 501 Not Implemented

The tag in server does not support the To header field serves functionality required to distinguish
responses at the UAC. It MUST be placed in fulfill the To field of
request. This is the appropriate response by user agent, registrar and redirect servers, but MUSTNOT
be inserted into responses forwarded upstream by proxies. However,
responses generated locally by a proxy, and then sent upstream, MUST
contain when a tag.

A UAS or redirect server MUST add a "tag" parameter for all final
responses does not
recognize the request method and is not capable of supporting it for
any user. (Proxies forward all transactions within requests regardless of method.)

11.5.3 502 Bad Gateway

The server, while acting as a call leg. All such parameters
have gateway or proxy, received an invalid
response from the same value within downstream server it accessed in attempting to
fulfill the same call leg. These servers SHOULD request.

11.5.4 503 Service Unavailable

Handley/Schulzrinne/Schooler/Rosenberg [Page 75] 91]

Internet Draft SIP November 24, 2000

add the tag for informational responses during May 29, 2001

The server is currently unable to handle the initial INVITE
transaction, but MUST add a tag request due to informational responses for all
subsequent transactions.

See Section 6.26 for details a
temporary overloading or maintenance of the "tag" parameter. server. The "tag"
parameter in To headers implication
is ignored when matching responses to
requests that did not contain this is a "tag" in their To header.

Section 11 describes when temporary condition which will be alleviated after
some delay. If known, the "tag" parameter MUST appear length of the delay MAY be indicated in
subsequent requests. Note that if a request already contained a tag,
this tag
Retry-After header. If no Retry-After is given, the client MUST be mirrored in
handle the response; a new tag MUSTNOT be
inserted.

Section 6.26 describes how To and From header fields are compared response as it would for
the purpose a 500 response.

Note: The existence of matching requests the 503 status code does not imply that a
server has to call legs.

UAS SHOULD accept requests even if they do use it when becoming overloaded. Some servers MAY wish
to simply refuse the connection.

11.5.5 504 Server Time-out

The server did not recognize receive a timely response from the URI
scheme server (e.g., a tel: URI) or
location server) it accessed in attempting to process the request.
Note that 408 (Request Timeout) should be used if there was no
response within the To period specified in the Expires header field from
the upstream server.

11.5.6 505 Version Not Supported

The server does not address support, or refuses to support, the
user. Only Request-URI SIP protocol
version that do not match was used in the recipient should cause
requests request message. The server is
indicating that it is unable or unwilling to be rejected.

Even if complete the "display-name" is empty, request
using the "name-addr" form MUST be
used if same major version as the "addr-spec" contains a comma, question mark, or
semicolon. Note client, other than with this
error message. The response MAY contain an entity describing why that LWS
version is common, but not mandatory between the
display-name supported and the "<".

The following what other protocols are examples of valid To headers:

To: supported by
that server. The Operator <sip:operator@cs.columbia.edu>;tag=287447
To: sip:+12125551212@server.phone2net.com

Call-ID, To format for such an entity is not defined here and From are needed to identify a call leg.
may be the subject of future standardization.

11.5.7 513 Message Too Large

The distinction between call and call leg matters in calls
with multiple server was unable to process the request since the message length
exceeded its capabilities.

11.6 Global Failures 6xx

6xx responses from indicate that a forked request. The "tag" is
added to server has definitive information about
a particular user, not just the To header field particular instance indicated in the response to allow
forking of future requests
Request-URI. All further searches for the same call by proxies,
while addressing only one of the possibly several
responding this user agent servers. It also allows several
instances of are doomed to failure
and pending searches SHOULD be terminated.

11.6.1 600 Busy Everywhere

The callee's end system was contacted successfully but the callee is
busy and does not wish to send requests that can be
distinguished.

6.45 Unsupported take the call at this time. The Unsupported response-header field lists response
MAY indicate a better time to call in the features Retry-After header. If the
callee does not
supported by wish to reveal the server. See Section 6.36 reason for a usage example and declining the call, the

Handley/Schulzrinne/Schooler/Rosenberg [Page 76] 92]

Internet Draft SIP November 24, 2000

motivation.

Syntax:

Unsupported = "Unsupported" ":" 1#option-tag

6.46 User-Agent

The User-Agent general-header field contains information about May 29, 2001

callee uses status code 603 (Decline) instead. This status response
is returned only if the client user agent originating knows that no other end point (such as
a voice mail system) will answer the request. Otherwise, 486 (Busy
Here) should be returned.

11.6.2 603 Decline

The syntax and semantics
are defined callee's machine was successfully contacted but the user
explicitly does not wish to or cannot participate. The response MAY
indicate a better time to call in [H14.42].

6.47 Via the Retry-After header.

11.6.3 604 Does Not Exist Anywhere

The Via field indicates server has authoritative information that the path taken by user indicated in
the To request so far. This
prevents request looping and ensures replies take field does not exist anywhere. Searching for the user
elsewhere will not yield any results.

11.6.4 606 Not Acceptable

The user's agent was contacted successfully but some aspects of the same path
session description such as the requests, which assists in firewall traversal and other unusual
routing situations.

6.47.1 Requests

The client originating requested media, bandwidth, or
addressing style were not acceptable.

A 606 (Not Acceptable) response means that the request MUST insert into user wishes to
communicate, but cannot adequately support the request session described. The
606 (Not Acceptable) response MAY contain a Via list of reasons in a
Warning header field containing describing why the transport protocol used session described cannot be
supported. Reasons are listed in Section 10.47. It is hoped that
negotiation will not frequently be needed, and when a new user is
being invited to join an already existing conference, negotiation may
not be possible. It is up to send the message, the
client's host name invitation initiator to decide
whether or network address and, if not the default port
number, the port number at which it wishes to receive responses.
(Note that act on a 606 (Not Acceptable) response.

12 SIP Message Body

12.1 Body Inclusion

Requests MAY contain message bodies unless otherwise noted. In this port number can differ from
specification, the UDP source port
number CANCEL request MUST NOT contain a message body.

The use of the request.) A fully-qualified domain name message bodies for REGISTER requests is RECOMMENDED.
Each subsequent proxy server that sends for further study.

For response messages, the request onwards MUST add
its own additional Via field before any existing Via fields. A proxy
that receives a redirection (3xx) method and the response status
code determine the type and then searches
recursively, MUST use interpretation of any message body. All
responses MAY include a body. Message bodies for 1xx responses
contain advisory information about the same Via headers as on progress of the original proxied request.

A proxy SHOULD check the top-most Via header field 1xx
responses to ensure that it
contains INVITE requests MAY contain session descriptions. Their
interpretation depends on the sender's correct network address, as seen from that
proxy. If response status code, but generally

Handley/Schulzrinne/Schooler/Rosenberg [Page 93]

Internet Draft SIP May 29, 2001

informs the sender's address caller what kind of session the callee is incorrect, likely to
establish, subject to later modification in the proxy MUST add an
additional "received" attribute, 2xx response.
Request methods not defined in this specification MAY also contain
session descriptions. 2xx responses to INVITE requests contain
session descriptions. In 3xx responses, the message body MAY contain
the description of alternative destinations or services, as described
in Section 6.47.2.

A multi-homed host may not be able to insert a network
address into 11.3. For responses with status 400 or greater, the Via header field that can be reached by
message body MAY contain additional, human-readable information about
the next hop, reasons for example because if one of the networks failure. It is
private. RECOMMENDED that information in 1xx
and 300 and greater responses be of type text/plain or text/html

12.2 Message Body Type

The address placed into Internet media type of the Via message body MUST be given by the
Content-Type header may differ
from field. If the interface actually used, body has undergone any encoding
(such as that interface is
selected only at packet sending time by the IP layer.

Handley/Schulzrinne/Schooler/Rosenberg [Page 77]

Internet Draft SIP November 24, 2000

A client that sends a request to a multicast address compression) then this MUST add be indicated by the
"maddr" parameter to its Via Content-
Encoding header field, and SHOULD add otherwise Content-Encoding MUST be omitted. If
applicable, the "ttl"
parameter. (In that case, character set of the maddr parameter SHOULD contain message body is indicated as
part of the
destination multicast address, although under exceptional
circumstances it Content-Type header-field value.

The "multipart" MIME type [38] MAY contain be used within the body of the
message. Clients that send requests containing multipart message
bodies MUST be able to send a unicast address.) If session description as a non-multipart
message body if the server receives
a request which contained requests this through an "maddr" parameter Accept header
field.

12.3 Message Body Length

The body length in the topmost Via
field, it bytes SHOULD send be given by the response to Content-Length header
field. Section 10.18 describes the address listed behavior in detail.

The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
(Note: The chunked encoding modifies the
"maddr" parameter.

Loop detection is described body of a message in Section 12.3.1.

6.47.2 Receiver-tagged Via Header Fields

Every host that sends or forwards order
to transfer it as a series of chunks, each with its own size
indicator.)

13 Compact Form

When SIP request adds is carried over UDP with authentication and a Via field
indicating the host's address. However, complex
session description, it is may be possible that Network
Address Translators (NATs) change the source size of a request or
response is larger than the MTU. To address and port this problem, a more
compact form of SIP is also defined by using abbreviations for the
request (e.g.,
common header fields listed below:

short field name long field name note
c Content-Type
e Content-Encoding

Handley/Schulzrinne/Schooler/Rosenberg [Page 94]

Internet Draft SIP May 29, 2001

f From
i Call-ID
k Supported from a net-10 to a globally routable address), "know"
l Content-Length
m Contact from "moved"
s Subject
t To
v Via

Thus, the message in
which case section 20.2 could also be written:

INVITE sip:bob@example.com SIP/2.0
v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16
v:SIP/2.0/UDP 216.112.6.38
f:sip:alice@wonderland.com
t:sip:bob@example.com
m:sip:alice@mouse.wonderland.com
i:62729-27@216.112.6.38
c:application/sdp
CSeq: 4711 INVITE
l:187

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

Clients MAY mix short field names and long field names within the Via header
same request. Servers MUST accept both short and long field cannot names for
requests. Proxies MAY change header fields between their long and
short forms, but this MUST NOT be relied on done to route replies.
To prevent this, fields following an
Authorization header.

14 Behavior of SIP Clients and Servers

14.1 Multicast Unreliable Transport Protocols

Requests MAY be multicast; multicast requests likely feature a proxy host-
independent Request-URI. This request SHOULD check the top-most Via header field be scoped to ensure that it contains

Handley/Schulzrinne/Schooler/Rosenberg [Page 95]

Internet Draft SIP May 29, 2001

is not forwarded beyond the sender's correct network address, as
seen from that proxy. If boundaries of the sender's address administrative scope.
This MAY be done with either TTL or administrative scopes [27],
depending on what is incorrect, implemented in the proxy
MUST add network.

A client receiving a "received" parameter multicast query does not have to check whether
the host part of the Request-URI matches its own host or domain name.
If the request was received via multicast, the response MUST be
returned to the Via header field inserted by address listed in the maddr parameter of the previous hop. Such a modified Via header field is known as a
receiver-tagged Via
header field.

An example is:

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3

In (This parameter is REQUIRED.) Generally, this example, the message originated from 10.0.0.1 and traversed will be a
NAT
multicast address. Such multicast responses are multicast with the external address border.ieee.org (199.172.136.3) to
reach erlang.bell-telephone.com. The latter noticed the mismatch,
and added a parameter to
same TTL as the previous hop's Via header field,
containing request, where the address that TTL is derived from the packet actually came from. (Note that ttl
parameter in the NAT border.ieee.org is not a SIP server.)

6.47.3 Responses Via header fields in responses are processed (Section 10.46).

To avoid response implosion, servers MUST NOT answer multicast
requests with a status code other than 2xx, 401, 407, 484 or 6xx. The
server delays its response by a random interval uniformly distributed
between zero and one second. Servers MAY suppress responses if they
hear a lower-numbered or 6xx response from another group member prior
to sending. Servers do not respond to CANCEL requests received via
multicast to avoid request implosion. A proxy or UAC
according to SHOULD send a
CANCEL on receiving the following rules:

1. The first Via header field should indicate the proxy 2xx, 401, 407 or
client 6xx response to a
multicast request.

Server response suppression is a MAY since it requires a
server to violate some basic message processing this response. If rules. Lets
say A sends a multicast request, and it does not, discard
the message. Otherwise, remove this Via field.

Handley/Schulzrinne/Schooler/Rosenberg [Page 78]

Internet Draft SIP November 24, 2000

2. If there is no second Via header field, this response is
destined for this client. Otherwise, use this received by B,
C, and D. B sends a 200 response. The topmost Via field as
the destination, as described in Section 6.47.5.

6.47.4 User Agent and Redirect Servers

A UAS or redirect server copies
the Via header fields into response will contain the address of A. C will also
receive this response, without changing their order, and uses the top (first) Via
element could use it to suppress its own
response. However, C would normally not examine this
response, as the destination, as described topmost Via is not its own. Normally, a
response received with an incorrect topmost Via MUST be
dropped, but not in this case. To distinguish this packet
from a misrouted or multicast looped packet is fairly
complex, and for this reason the next section.

6.47.5 Forwarding Responses

Given procedure is a destination described by MAY. The
CANCEL, instead, provides a Via header field, the simpler and more standard way
to perform response suppression. It is
sent according to the following rules:

o If for this reason that
the "sent-protocol" use of CANCEL here is a SHOULD.

14.2 Reliable Transport Protocols

A single reliable transport protocol connection such as TCP, TLS TCP can serve one or SCTP, send
more SIP transactions. A transaction contains zero or more
provisional responses followed by one or more final responses.
(Typically, transactions contain exactly one final response, but
there are exceptional circumstances, where, for example, multiple 200
responses can be generated.) The client SHOULD keep the connection

Handley/Schulzrinne/Schooler/Rosenberg [Page 96]

Internet Draft SIP May 29, 2001

open at least until the first final response using arrives.

The server SHOULD NOT close the existing TCP connection to until it has sent its
final response (and possibly received the source of ACK), at which point it MAY
close the original request.

o Otherwise, TCP connection if it wishes to. However, normally it is the Via header field contains a "maddr"
parameter, forward the response
client's responsibility to close the address listed there,
using connection.

If the port indicated in "sent-by", or port 5060 server leaves the connection open, and if none is
present. If the address is a multicast address, client so
desires it MAY re-use the response
SHOULD connection for further SIP requests. These
requests can be sent using the TTL indicated in for the "ttl" parameter, same transaction or with a TTL of 1 if that parameter call, or for totally
different transactions or calls. There is not present.

o Otherwise, if it no requirement that a
transaction must complete before a new one is initiated on an
existing connection. As a receiver-tagged field (Section 6.47.2),
send result, a server MUST support receiving a
request for a new transaction on an existing connection before the
previous transaction on the same connection has completed.

If a server needs to return a response to the address in the "received" parameter,
using the port indicated in the "sent-by" value, or using port
5060 if none is specified explicitly.

o Otherwise, if a client and no longer has
a connection open to that client, it is not receiver-tagged, send the response MAY open a connection to the
address indicated by the "sent-by" value listed in the second Via
header field.

Note that the response header. Thus, a proxy or user agent MUST be
prepared to receive both requests and responses on a "passive"
connection.

14.3 Reliability for Requests Other Than INVITE

14.3.1 Unreliable Transport Protocols

A SIP client using an unreliable datagram request is not
returned to the port from which transport protocol such as UDP
SHOULD retransmit requests other than INVITE or ACK with an
exponential backoff, starting at a T1 second interval, doubling the request came.

6.47.6 Syntax

The format
interval for each packet, and capping off at a Via header field T2 second interval.
This means that after the first packet is shown in Fig. 10. The "maddr"
parameter, designating sent, the multicast address, and second is sent T1
seconds later, the "ttl"
parameter, designating next 2*T1 seconds after that, the time-to-live (TTL) value, are included
only if next 4*T1
seconds after that, and so on, until the request was sent via multicast. The "received" parameter
is added only for receiver-added Via fields (Section 6.47.2).

The "branch" parameter is included interval reaches T2.
Subsequent retransmissions are spaced by every proxy. The token MUST be

Handley/Schulzrinne/Schooler/Rosenberg [Page 79]

Internet Draft SIP November 24, 2000

Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by
*( ";" via-params ) [ comment ] )
via-params = via-hidden | via-ttl | via-maddr
| via-received | via-branch | via-extension
via-hidden = "hidden"
via-ttl = "ttl" "=" ttl
via-maddr = "maddr" "=" host
via-received = "received" "=" host
via-branch = "branch" "=" token
via-extension = generic-param
sent-protocol = protocol-name "/" protocol-version "/" transport
protocol-name = "SIP" | token
protocol-version = token
transport = "UDP" | "TCP" | token
sent-by = host [ ":" port ]

Figure 10: Syntax T2 seconds. If the client
receives a provisional response, it continues to retransmit the
request, but with an interval of Via header field

unique T2 seconds. Retransmissions cease
when the client has sent a total of eleven packets, or receives a
definitive response. Default values for each distinct request. The precise format T1 and T2 are 500 ms and 4 s,
respectively. Clients MAY use larger values, but SHOULD NOT use
smaller ones. Servers retransmit the response upon receipt of a
request retransmission. After the token is
implementation-defined. In order to server sends a final response, it
cannot be able to both detect loops and
associate responses with sure the corresponding request, client has received the parameter response, and thus SHOULD consist of two parts separable by
cache the implementation. One
part, used results for loop detection (Section 12.3.1), MAY be computed as at least 10*T2 seconds to avoid having to, for
example, contact the user or location server again upon receiving a
cryptographic hash
request retransmission.

Use of the To, From, Call-ID header fields, the
Request-URI of exponential backoff is for congestion control

Handley/Schulzrinne/Schooler/Rosenberg [Page 97]

Internet Draft SIP May 29, 2001

purposes. However, the back-off must cap off, since request received (before translation) and
retransmissions are used to trigger response
retransmissions at the
sequence number from server. Without a cap, the CSeq header field. loss of a
single response could significantly increase transaction
latencies.

The algorithm used to
compute value of the hash is implementation-dependent, but MD5 [36], expressed
in hexadecimal, initial retransmission timer is a reasonable choice. (Note smaller than that base64
that for TCP since it is not
permissible expected that network paths suitable for
interactive communications have round-trip times smaller than 500 ms.
For congestion control purposes, the retransmission count has to be
bounded. Given that most transactions are expected to consist of one
request and a token.) The other part, used for matching responses few responses, round-trip time estimation is not likely
to requests, be very useful. If RTT estimation is desired to more quickly
discover a globally unique function of missing final response, each request retransmission needs
to be labeled with its own Timestamp (Section 10.42), returned in the branch taken, for
example,
response. The server caches the result until it can be sure that the
client will not retransmit the same request again.

Each server in a hash of proxy chain generates its own final response to a sequence number, local IP address and request-
URI
CANCEL request. The server responds immediately upon receipt of the
CANCEL request sent on