5.

Response
After receiving and interpreting a request message, the recipient
responds with a SIP response message. The response message format
is shown below:

Response := Status-Line *( general-header | response-header |

entity-header ) CRLF [ message-body ]

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

here.

5.1. Status-Line

The first line of a Response message is the Status-Line, consisting of

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 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 indicates the

outcome of the attempt to understand and satisfy the request. The
Reason-Phrase is intended to give a short textual description of the
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 := Informational | Success | Redirection | Client-

Error | Server-Error | Global-Failure | extension-code
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. The first digit of the Status-Code defines the
class of response. The last two digits do not have any categorization
role. SIP/2.0 allows 6 values for the first digit:

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

request;

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

accepted;
 3xx: Redirection -- further action needs to be taken in order to
complete the request;

4xx: Client Error -- the request contains bad syntax or cannot be

fulfilled at this server;

5xx: Server Error -- the server failed to fulfill an apparently valid

request;

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

Figures 5 through 9 present the individual values of the numeric

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 protocol. Note that
SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response
codes in the range starting at x80 to avoid conflicts with newly defined
HTTP response codes, and adds a new class, 6xx, of response codes.

SIP response codes are extensible. SIP applications are not required to
understand the meaning of all registered response codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any response code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 response code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if a client
receives an unrecognized response code of 431, it can safely assume
that there was something wrong with its request and treat the
response as if it had received a 400 (Bad Request) response code. In
such cases, user agents SHOULD present to the user the message
body returned with the response, since that message body is likely to
include human-readable information which will explain the unusual
status.

Informational := "100" | "180" | "181" | "182"

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

Figure 5: Informational and success status codes

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

Figure 6: Redirection status codes

Client-Error := "400" | "401" | "402" | "403" | "404" | "405" | "406" |
"407" | "408" | "409" | "410" | "411" | "413" | "414" | "415" | "420" |
"480" | "481" | "482" | "483" | "484" | "485" | "486"
Client-Error = "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Timeout
| "409" ; Conflict
| "410" ; Gone
| "411" ; Length Required
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "420" ; Bad Extension
| "480" ; Temporarily not available
| "481" ; Call Leg/Transaction Does Not Exist
| "482" ; Loop Detected
| "483" ; Too Many Hops
| "484" ; Address Incomplete
| "485" ; Ambiguous
| "486" ; Busy Here

Figure 7: Client error status codes

Server-Error := "500" | "501" | "502" | "503" | "504" | "505"
Server-Error = "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; SIP Version not supported

Figure 8: Server error status codes

6. Header Field Definitions

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
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
Global-Failure := "600" | "603" | "604" | "606"
Global-Failure | "600" ; Busy Everywhere
| "603" ; Decline
| "604" ; Does not exist anywhere
| "606" ; Not Acceptable

Figure 9: Global failure status codes

rules in [H4.2] regarding ordering of header fields apply to SIP, with the
exception of Via fields, see below, whose order matters. Additionally,
header fields which are hop-by-hop MUST appear before any header
fields which are end-to-end. Proxies SHOULD NOT reorder header
fields. Proxies add Via header fields and MAY add other hop- by-hop
header fields. They can modify certain header fields, such as Max-
Forwards (Section 6.23) and "fix up" the Via header fields with
"received" parameters as described in Section 6.40.1. Proxies MUST
NOT alter any fields that are authenticated (see Section 13.2).

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. A "*" indicates that
the header fields are needed only if message body is not empty. See
sections 6.15, 6.16 and 8 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 6.1) and entity header (Section 6.2) fields, respectively. If a
header field is marked "c", it is copied from the request to the
response.

The "enc." column describes whether this message header field MAY be
encrypted end-to-end. A "n" designates fields that MUST NOT be
encrypted, while "c" designates fields that SHOULD be encrypted if
encryption is used.

The "e-e" column has a value of "e" for end-to-end and a value of "h"
for hop-by-hop header fields.

where enc. e-e ACK BYE CAN INV OPT REG

__________________________________________________________
Accept R e - - - o o o
Accept 415 e - - - o o o
Accept-Encoding R e - - - o o o
Accept-Encoding 415 e - - - o o o
 Accept-Language R e - o o o o o
Accept-Language 415 e - o o o o o
Allow 200 e - - - - m -
Allow 405 e o o o o o o
Authorization R e o o o o o o
Call-ID gc n e m m m m m m
Contact R e o - - o o o
Contact 1xx e - - - o o -
Contact 2xx e - - - o o o
Contact 3xx e - o - o o o
Contact 485 e - o - o o o
Content-Encoding e e o - - o o o
Content-Length e e o - - o o o
Content-Type e e * - - * * *
CSeq gc n e m m m m m m
Date g e o o o o o o
Encryption g n e o o o o o o
Expires g e - - - o - o
From gc n e m m m m m m
Hide R n h o o o o o o
Max-Forwards R n e o o o o o o
Organization g c h - - - o o o

Table 4: Summary of header fields, A--O

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 9 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.

6.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

where enc. e-e ACK BYE CAN INV OPT REG

___________________________________________________________________
Proxy-Authenticate 407 n h o o o o o o
Proxy-Authorization R n h o o o o o o
Proxy-Require R n h o o o o o o
Priority R c e - - - o - -
Require R e o o o o o o
Retry-After R c e - - - - - o
Retry-After 404,480,486 c e o o o o o o
503 c e o o o o o o
 600,603 c e o o o o o o
Response-Key R c e - o o o o o
Record-Route R h o o o o o o
Record-Route 2xx h o o o o o o
Route R h o o o o o o
Server r c e o o o o o o
Subject R c e - - - o - -
Timestamp g e o o o o o o
To gc(1) n e m m m m m m
Unsupported 420 e o o o o o o
User-Agent g c e o o o o o o
Via gc(2) n e m m m m m m
Warning r e o o o o o o
WWW-Authenticate 401 c e o o o o o o

Table 5: Summary of header fields, P--Z; (1): copied with possible

addition of tag; (2): UAS removes first Via header field

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.

6.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.

6.3. Request Header Fields

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.

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.

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

6.5. End-to-end and Hop-by-hop Headers

End-to-end headers MUST be transmitted unmodified across all

proxies, while hop-by-hop headers MAY be modified or added by
proxies.

6.6. 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 822std11(-> 2822prop) [24]. 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.

Field names are not case-sensitive, although their values may be.

6.7. 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.

This request-header field is used only with the INVITE, OPTIONS and
REGISTER request methods to indicate what media types are
acceptable in the response.

Example:

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

6.8. Accept-Encoding

The Accept-Encoding request-header field is similar to Accept, but

restricts the content-codings [H3.4.1] 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].

6.9. Accept-Language

The Accept-Language 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 request-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

6.10. Allow
The Allow entity-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 and SHOULD be present in an OPTIONS response.

Allow := "Allow" ":" 1#Method

6.11. Authorization

A user agent that wishes to authenticate itself with a server -- usually,

but not necessarily, after receiving a 401 response -- MAY do so by
including an Authorization request-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 13.2 overviews the use of the Authorization header, and

section 15 describes the syntax and semantics when used with PGP
based authentication.

6.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.
The REGISTER and OPTIONS methods use the Call-ID 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.

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.

Call-ID := ( "Call-ID" | "i" ) ":" local-id "@" host

local-id := 1*uric

"host" SHOULD be either a fully qualified domain name or a globally

routable IP address. If this is the case, the "local-id" SHOULD be an
identifier consisting of URI characters that is unique within "host". Use
of cryptographically random identifiers [27] is RECOMMENDED. If,
however, host is not an FQDN or globally routable IP address (such as a
net 10 address), the local-id MUST be globally unique, as opposed to
unique within host. These rules guarantee overall global uniqueness of
the Call-ID. The value for Call-ID MUST NOT be reused for a different
call. Call-IDs are case-sensitive.

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
9. 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

or

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

6.13. Contact

The Contact general-header field can appear in INVITE, ACK, and

REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In
general, it provides a URL where the user can be reached for further
communications.
INVITE and ACK requests: INVITE and ACK requests MAY contain Contact
headers indicating from which location the request is
originating.

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 2xx responses: A user agent server sending a definitive,

positive response (2xx) MAY insert a Contact response header
field indicating the SIP address under which it is reachable
most directly for future SIP requests, such as ACK, within the
same Call-ID. The Contact header field contains the address of
the server itself or that of a proxy, e.g., if the host is
behind a firewall. The value of this Contact header is copied
into the Request-URI of subsequent requests for this call if the
response did not also contain a Record-Route header. If the
response also contains a Record-Route header field, the address
in the Contact header field is added as the last item in the
Route header field. See Section 6.29 for details.

The Contact value SHOULD NOT be cached across calls, as it

may not represent the most desirable location for a
particular destination address.

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.

REGISTER requests: REGISTER requests MAY contain a Contact header

field indicating at which locations the user is reachable. The
REGISTER request defines a wildcard Contact field, "*", which
MUST only be used with Expires: 0 to remove all registrations
for a particular user. An optional "expires" parameter indicates
the desired expiration time of the registration. If a Contact
entry does not have an "expires" parameter, the Expires header
field is used as the default value. If neither of these
mechanisms is used, SIP URIs are assumed to expire after one
hour. Other URI schemes have no expiration times.

REGISTER 2xx responses: A REGISTER response MAY return all locations

at which the user is currently reachable. An optional "expires"
parameter indicates the expiration time of the registration. If
a Contact entry does not have an "expires" parameter, the value
of the Expires header field indicates the expiration time. If
neither mechanism is used, the expiration time specified in the
request, explicitly or by default, is used.

3xx and 485 responses: The Contact response-header field can be used
with a 3xx 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 transport parameters. A 300
 (Multiple Choices), 301 (Moved Permanently), 302 (Moved
Temporarily) or 485 (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 the "user", "password", "host", "port" and "user-
param" elements of the Contact URI into the Request-URI of the
redirected request and directs the request to the address
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.

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 2368prop, [28]) 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.

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 number indicating seconds or a quoted
string containing a SIP-date. If this parameter is not provided,
the value of the Expires header field determines how long the
URI is valid. Implementations MAY treat values larger than
2**32-1 (4294967295 seconds or 136 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
contact-params := "q" "=" qvalue | "action" "=" "proxy" | "redirect" |
"expires" "=" delta-seconds | " SIP-date " | extension-attribute
extension-attribute := extension-name [ "=" extension-value ]

only allows one address, unquoted. Since URIs can contain commas
and semicolons as reserved characters, they can be mistaken for
header or parameter delimiters, respectively. The current syntax
corresponds to that for the To and From header, which also allows 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

6.14. 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
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 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 [3.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 in the request.
6.15. Content-Length

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

message-body, in decimal number of octets, sent to 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. Any
Content-Length greater than or equal to zero is a valid value. If no
body is present in a message, then the Content-Length header field
MUST be set to zero. If a server receives a UDP request without
Content-Length, it MUST assume that the request encompasses the
remainder of the packet. If a server receives a UDP request with a
Content-Length, but the value is larger than the size of the body sent
in the request, the client SHOULD generate a 400 class response. If
there is additional data in the UDP packet after the last byte of the
body has been read, the server MUST treat the remaining data as a
separate message. This allows several messages to be placed in a
single UDP packet.

If a response does not contain a Content-Length, the client assumes

that it encompasses the remainder of the UDP packet or the data until
the TCP connection is closed, as applicable. Section 8 describes how to
determine the length of the message body.

6.16. 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].

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.17. CSeq
Clients MUST add the CSeq (command sequence) general-header field
to every request. A CSeq header field in a request contains the request
method and a single decimal sequence number chosen by the
requesting client, unique within a single value of Call-ID. The sequence
number MUST be expressible as a 32-bit unsigned integer. The initial
value of the sequence number is arbitrary, but MUST be less than
2**31. Consecutive requests that differ in request method, headers or
body, but have the same Call-ID MUST contain strictly monotonically
increasing and contiguous sequence numbers; sequence numbers do
not wrap around. Retransmissions of the same request carry the same
sequence number, but an INVITE with a different message body or
different header fields (a "re-invitation") acquires a new, higher
sequence number. A server MUST echo the CSeq value from the
request in its response. If the Method value is missing in the received
CSeq header field, the server fills it in appropriately.

The ACK and CANCEL requests MUST contain the same CSeq value as
the INVITE request that it refers to, while a BYE request cancelling an
invitation MUST have a higher sequence number. A BYE request with a
CSeq that is not higher should cause a 400 response to be generated.

A user agent server MUST remember the highest sequence number for
any INVITE request with the same Call-ID value. 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 the parallel search.

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

Strictly speaking, CSeq header fields are needed for any SIP request
that can be cancelled by a BYE or CANCEL request or where a client
can issue several requests for the same Call-ID in close succession.
Without a sequence number, the response to an INVITE could be
mistaken for the response to the cancellation (BYE or CANCEL). Also, if
the network duplicates packets or if an ACK is delayed until the server
has sent an additional response, the client could interpret an old
response as the response to a re- invitation issued shortly thereafter.
Using CSeq also makes it easy for the server to distinguish different
versions of an invitation, without comparing the message body.

The Method value allows the client to distinguish the response to an

INVITE request from that of a CANCEL response. CANCEL requests can
be generated by proxies; if they were to increase the sequence
number, it might conflict with a later request issued by the user agent
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 to wrap
around. The initial value of the sequence number is 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.

Forked requests MUST have the same CSeq as there would be

ambiguity otherwise between these forked requests and later BYE
issued by the client user agent.

Example:

CSeq: 4711 INVITE

6.18. Date

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

SIP-date := rfc1123-date

See [H14.19] for a definition of rfc1123-date. Note that unlike

HTTP/1.1, SIP only supports the most recent RFC 1123std3 [29]
formatting for dates.

The Date header field reflects the time when the request or response is
first sent. Thus, retransmissions have the same Date header field value
as the original.

The Date header field can be used by simple end systems without a
battery-backed clock to acquire a notion of current time.

6.19. Encryption

The Encryption general-header field specifies that the content has

been encrypted. Section 13 describes the overall SIP security
architecture and algorithms. This header field is intended for end- to-
end encryption of requests and responses. Requests are encrypted
based on the public key belonging to the entity named in the To header
field. Responses are encrypted based on the public key conveyed in
the Response-Key header field. Note that the public keys themselves
may not be used for the encryption. This depends on the particular
algorithms used.

For any encrypted message, at least the message body and possibly
other message header fields are encrypted. An application receiving a
request or response containing an Encryption header field decrypts the
body and then concatenates the plaintext to the request line and
headers of the original message. Message headers in the decrypted
part completely replace those with the same field name in the
plaintext part. (Note: If only the body of the message is to be
encrypted, the body has to be prefixed with CRLF to allow proper
concatenation.) Note that the request method and Request-URI cannot
be encrypted.

Encryption only provides privacy; the recipient has no guarantee that

the request or response came from the party listed in the From
message header, only that the sender used the recipient's public key.
However, proxies will not be able to modify the request or response.

Encryption := "Encryption" ":" encryption-scheme 1*SP

#encryption-params
encryption-scheme := token
encryption-params := token "=" ( token | quoted-string )

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

section 13.

The example in Figure 10 shows a message encrypted with ASCII-

armored PGP that was generated by applying "pgp -ea" to the payload
to be encrypted.

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
Content-Length: 885
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+

Figure 10: PGP Encryption Example

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 as an otherwise
identical un-encrypted request.

6.20. Expires

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

This header field is currently defined only for the REGISTER and INVITE
methods. For REGISTER, it is a request and response-header field. In a
REGISTER request, the client indicates how long it wishes the
registration to be valid. In the response, the server indicates the
earliest expiration time of all registrations. The server MAY choose a
shorter time interval than that requested by the client, but SHOULD
NOT choose a longer one.

For INVITE requests, it is a request and response-header field. In a

request, the caller can limit the validity of an invitation, for example, if
a client wants to limit the time duration of a search or a conference
invitation. A user interface MAY take this as a hint to leave the
invitation window on the screen even if the user is not currently at the
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 client of the maximal duration of the redirection.

The value of this field can be either a SIP-date or an integer number of

seconds (in decimal), measured from the receipt of the request. The
latter approach is preferable for short durations, as it does not depend
on clients 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 of its use are

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

 Expires: 5

6.21. From

Requests and responses MUST contain a From general-header field,

indicating the initiator of the request. The From field MAY contain the
"tag" parameter. The server copies the From header field from the
request to the response. The optional "display-name" is meant to be
rendered by a human-user interface. A system SHOULD use the display
name "Anonymous" if the identity of the client is to 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 removes them before further processing.

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

used if the "addr-spec" contains a comma, question mark, or
semicolon.

From := ( "From" | "f" ) ":" ( name-addr | addr-spec ) *( ";" addr-

params )
addr-params := tag-param
tag-param := "tag=" UUID
UUID := 1*( hex | "-" )

Examples:

From: "A. G. Bell" <sip:agb@bell-telephone.com>

From: sip:+12125551212@server.phone2net.com
From: Anonymous <sip:c8oqz84zk7z@privacy.org>

The "tag" MAY appear in the From field of a request. It MUST be present
when it is possible that two instances of a user sharing a SIP address
can make call invitations with the same Call-ID.

The "tag" value MUST be globally unique and cryptographically random

with at least 32 bits of randomness. A single user maintains the same
tag throughout the call identified by the Call-ID.

Call-ID, To and From are needed to identify a call leg. The distinction
between call and call leg matters in calls with multiple responses to a
forked request. The format is similar to the equivalent RFC 822std11(->
2822prop) [24] header, but with a URI instead of just an email address.

6.22. Hide
A client uses the Hide request header field to indicate that it wants the
path comprised of the Via header fields (Section 6.40) to be hidden
from subsequent proxies and user agents. It can take two forms: Hide:
route and Hide: hop. Hide header fields are typically added by the
client user agent, but MAY be added by any proxy along the path.

If a request contains the "Hide: route" header field, all following proxies
SHOULD hide their previous hop. If a request contains the "Hide: hop"
header field, only the next proxy SHOULD hide the previous hop and
then remove the Hide option unless it also wants to remain
anonymous.

A server hides the previous hop by encrypting the "host" and "port"
parts of the top-most Via header field with an algorithm of its choice.
Servers SHOULD add additional "salt" to the "host" and "port"
information prior to encryption to prevent malicious downstream
proxies from guessing earlier parts of the path based on seeing
identical encrypted Via headers. Hidden Via fields are marked with the
"hidden" Via option, as described in Section 6.40.

A server that is capable of hiding Via headers MUST attempt to decrypt

all Via headers marked as "hidden" to perform loop detection. Servers
that are not capable of hiding can ignore hidden Via fields in their loop
detection algorithm.

If hidden headers were not marked, a proxy would have to decrypt all
headers to detect loops, just in case one was encrypted, as the Hide:
Hop option may have been removed along the way.

A host MUST NOT add such a "Hide: hop" header field unless it can
guarantee it will only send a request for this destination to the same
next hop. The reason for this is that it is possible that the request will
loop back through this same hop from a downstream proxy. The loop
will be detected by the next hop if the choice of next hop is fixed, but
could loop an arbitrary number of times otherwise.

A client requesting "Hide: route" can only rely on keeping the request
path private if it sends the request to a trusted proxy. Hiding the route
of a SIP request is of limited value if the request results in data packets
being exchanged directly between the calling and called user agent.

The use of Hide header fields is discouraged unless path privacy is

truly needed; Hide fields impose extra processing costs and restrictions
for proxies and can cause requests to generate 482 (Loop Detected)
responses that could otherwise be avoided.
The encryption of Via header fields is described in more detail in
Section 13.

The Hide header field has the following syntax:

Hide := "Hide" ":" ( "route" | "hop" )

6.23. Max-Forwards

The Max-Forwards request-header field may be used with any SIP

method to limit the 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 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 remaining

number of times this request message is 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 recipient
MUST NOT forward the request. Instead, for the OPTIONS and
REGISTER methods, it MUST respond as the final recipient. For all other
methods, the server returns 483 (Too many hops).

If the received Max-Forwards value is greater than zero, then the

forwarded message MUST contain an updated Max-Forwards field with
a value decremented by one (1).

Example:

Max-Forwards: 6

6.24. Organization

The Organization general-header field conveys the name of the

organization to which the entity issuing the request or 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

6.25. Priority

The Priority request-header field indicates the urgency of the request

as perceived by the client.

Priority := "Priority" ":" priority-value

priority-value := "emergency" | "urgent" | "normal" | "non-urgent"

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

life, limb or property are in imminent danger.

Examples:

Subject: A tornado is heading our way!

Priority: emergency

Subject: Weekend plans

Priority: non-urgent

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

6.26. Proxy-Authenticate

The Proxy-Authenticate response-header field MUST be included as

part of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and
parameters applicable to the proxy for this Request-URI.

Unlike its usage within HTTP, the Proxy-Authenticate header MUST be

passed upstream in 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 14 for further
details on its usage.

A client SHOULD cache the credentials used for a particular proxy

server and realm for the next request to that server. Credentials are, in
general, valid for a specific value of the Request-URI at a particular
proxy server. If a client contacts a proxy server that has required
authentication in the past, but the client does not have credentials for
the 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 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.

6.27. Proxy-Authorization

The Proxy-Authorization request-header field allows the client to

identify itself (or its user) to a proxy which requires authentication. The
Proxy-Authorization field value consists of credentials containing the
authentication information of the user agent for the proxy and/or realm
of the resource being requested.

Unlike Authorization, the Proxy-Authorization header field applies only

to the next outbound proxy that demanded authentication using the
Proxy- Authenticate field. When multiple proxies are used in a chain,
the Proxy-Authorization header field is consumed by the first outbound
proxy that was expecting to receive credentials. A proxy MAY relay the
credentials from the client request to the next proxy if that is the
mechanism 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.28. Proxy-Require

The Proxy-Require header field is used to indicate proxy-sensitive

features that MUST be supported by the proxy. Any Proxy-Require
header field features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client if not supported.
Proxy servers treat this field identically to the Require field.

See Section 6.30 for more details on the mechanics of this message
and a usage example.

6.29. Record-Route

The Record-Route request and response header field is added to a

request by any proxy that insists on being in the path of subsequent
requests for the same call leg. It contains a globally reachable Request-
URI that identifies the proxy server. Each proxy server adds its
Request-URI to the beginning of the list.

The server copies the Record-Route header field unchanged into the
response. (Record-Route is only relevant for 2xx responses.)
The calling user agent client copies the Record-Route header into a
Route header field of subsequent requests within the same call leg,
reversing the order of requests, so that the first entry is closest to the
user agent client. If the response contained a Contact header field, the
calling user agent adds its content as the last Route header. Unless this
would cause a loop, any client MUST send any subsequent requests for
this call leg to the first Request-URI in the Route request header field
and remove that entry.

The calling user agent MUST NOT use the Record-Route header field in
requests that contain Route header fields.

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 and ACK packets for the call.

The Record-Route header field has the following syntax:

Record-Route := "Record-Route" ":" 1# name-addr

Proxy servers SHOULD use the "maddr" URL parameter containing their
address to ensure that subsequent requests are guaranteed to reach
exactly the same server.

Example for a request that has traversed the hosts ieee.org and bell-
telephone.com , in that order:

Record-Route: <sip:a.g.bell@bell-telephone.com>,
<sip:a.bell@ieee.org>

6.30. Require

The Require request-header field is used by clients to tell user agent

servers about options that the client expects the server to support 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) 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

This is 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 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 redirect servers MUST ignore features that are not
understood. If a particular extension requires that intermediate devices
support it, the extension MUST be tagged in the Proxy-Require field as
well (see Section 6.28).

6.31. Response-Key

The Response-Key request-header field can be used by a client to

request the key that the called user agent SHOULD use to encrypt the
response with. The syntax is:

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

param
key-scheme := token
key-param := token "=" ( token | quoted-string )

The "key-scheme" gives the type of encryption to be used for the

response. Section 13 describes security schemes.

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 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 is
not present, a server SHOULD still encrypt if it can.

6.32. Retry-After

The Retry-After general-header field can be used with a 503 (Service

Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client and with a 404 (Not Found), 600
(Busy), or 603 (Decline) response to indicate when 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 the time
of the response.

A REGISTER request MAY include this 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 is given, the service is assumed to
be available indefinitely.

Retry-After := "Retry-After" ":" ( SIP-date | delta-seconds ) [

comment ] [ ";" "duration" "=" delta-seconds ]

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, the callee is reachable for one hour starting at
21:00 GMT. In the last example, the delay is 2 minutes.

6.33. Route

The Route request-header field determines the route taken by a

request. Each host removes the first entry and then proxies the request
to the host listed in that entry, also using it as the Request-URI. The
operation is further described in Section 6.29.

The Route header field has the following syntax:

Route := "Route" ":" 1# name-addr

6.34. Server

The Server response-header field contains information about the

software used by the user agent server to handle the request. The
syntax for this field is defined in [H14.39].
6.35. Subject

This is intended to provide a summary, or to indicate the nature, of the

call, allowing call filtering without having to parse the session
description. (Also, the session description does not have to use the
same subject indication as the invitation.)

Subject := ( "Subject" | "s" ) ":" *TEXT-UTF8

Example:

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

6.36. Timestamp

The timestamp general-header field describes when the client sent the
request to the server. The value of the timestamp is of significance
only to the client and it MAY use any timescale. The server MUST echo
the exact same value and MAY, if it has accurate information about
this, add a floating point number indicating the number of seconds that
have elapsed since it has received the request. The timestamp is used
by the client to compute the round-trip time to the server so that it can
adjust the timeout value for retransmissions.

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

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

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

6.37. To

The To general-header field specifies recipient of the request, with the

same SIP URL syntax as the From field.

To := ( "To" | "t" ) ":" ( name-addr | addr-spec ) *( ";" addr-params )

Requests and responses MUST contain a To general-header field,

indicating the desired recipient of the request. The optional "display-
name" is meant to be rendered by a human-user interface. The UAS or
redirect server copies the To header field into its response, and MUST
add a "tag" parameter if the request contained more than one Via
header field.
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 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 "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, 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 the responses from each at
the caller. The situation also arises with multicast requests. The tag in
the To header field serves to distinguish responses at the UAC. It MUST
be placed in the To field of the response by each instance when there is
a possibility that the request was forked at an intermediate proxy. The
"tag" MUST be added by UAS, registrars and redirect servers, but MUST
NOT be inserted into responses forwarded upstream by proxies. The
"tag" is added for all definitive responses for all methods, and MAY be
added for informational responses from a UAS or redirect server. All
subsequent transactions between two entities MUST include the "tag"
parameter, as described in Section 11.

See Section 6.21 for details of the "tag" parameter.

The "tag" parameter in To headers is ignored when matching responses

to requests that did not contain a "tag" in their To header.

A SIP server returns a 400 (Bad Request) response if it receives a

request with a To header field containing a URI with a scheme it does
not recognize.

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

used if the "addr-spec" contains a comma, question mark, or
semicolon.

The following are examples of valid To headers:

To: The Operator <sip:operator@cs.columbia.edu>;tag=287447

To: sip:+12125551212@server.phone2net.com

Call-ID, To and From are needed to identify a call leg. The distinction
between call and call leg matters in calls with multiple responses from
a forked request. The "tag" is added to the To header field in the
response to allow forking of future requests for the same call by
proxies, while addressing only one of the possibly several responding
user agent servers. It also allows several instances of the callee to
send requests that can be distinguished.

6.38. Unsupported

The Unsupported response-header field lists the features not supported

by the server. See Section 6.30 for a usage example and motivation.

Syntax:

Unsupported := "Unsupported" ":" 1#option-tag

6.39. 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.42].

6.40. Via

The Via field indicates the path taken by the 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.

6.40.1. Requests

The client originating the request MUST insert into the request a Via
field containing its host name or network address and, if not the
default port number, the port number at which it wishes to receive
responses. (Note that this port number can differ from the UDP source
port number of the request.) A fully-qualified domain name is
RECOMMENDED. Each subsequent proxy server that sends the request
onwards MUST add its own additional Via field before any existing Via
fields. A proxy that receives a redirection (3xx) response and then
searches recursively, MUST use the same Via headers as on the
original proxied request.

A proxy SHOULD check the top-most Via header field to ensure that it
contains the sender's correct network address, as seen from that proxy.
If the sender's address is incorrect, the proxy MUST add an additional
"received" attribute, as described 6.40.2.
A host behind a network address translator (NAT) or firewall may not
be able to insert a network address into the Via header that can be
reached by the next hop beyond

the NAT. Use of the received attribute allows SIP requests to traverse
NAT's which only modify the source IP address. NAT's which modify port
numbers, called Network Address Port Translator's (NAPT) will not
properly pass SIP when transported on UDP, in which case an
application layer gateway is required. When run over TCP, SIP stands a
better chance of traversing NAT's, since its behavior is similar to HTTP
in this case (but of course on different ports).

A proxy sending a request to a multicast address MUST add the

"maddr" parameter to its Via header field, and SHOULD add the "ttl"
parameter. If a server receives a request which contained an "maddr"
parameter in the topmost Via field, it SHOULD send the response to the
multicast address listed in the "maddr" parameter.

If a proxy server receives a request which contains its own address in

the Via header value, it MUST respond with a 482 (Loop Detected)
status code.

A proxy server MUST NOT forward a request to a multicast group which

already appears in any of the Via headers.

This prevents a malfunctioning proxy server from causing loops. Also, it

cannot be guaranteed that a proxy server can always detect that the
address returned by a location service refers to a host listed in the Via
list, as a single host may have aliases or several network interfaces.

6.40.2. Receiver-tagged Via Header Fields

Normally, every host that sends or forwards a SIP message adds a Via
field indicating the path traversed. However, it is possible that Network
Address Translators (NATs) changes the source address and port of the
request (e.g., from net-10 to a globally routable address), in which case
the Via header field cannot be relied on to route replies. To prevent
this, a proxy SHOULD check the top-most Via header field to ensure
that it contains the sender's correct network address, as seen from that
proxy. If the sender's address is incorrect, the proxy MUST add a
"received" parameter to the Via header field inserted by 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 example, the message originated from 10.0.0.1 and traversed a
NAT 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 the previous hop's Via header field, containing the
address that the packet actually came from. (Note that the NAT
border.ieee.org is not a SIP server.)

6.40.3. Responses

Via header fields in responses are processed by a proxy or UAC

according to the following rules:

1. The first Via header field should indicate the proxy or

client processing this response. If it does not, discard
the message. Otherwise, remove this Via field.

2. If there is no second Via header field, this response is

destined for this client. Otherwise, the processing depends
on whether the Via field contains a "maddr" parameter or is
a receiver-tagged field:

- If the second Via header field contains a "maddr"

parameter, send the response to the multicast address
listed there, using the port indicated in "sent-by", or
port 5060 if none is present. The response SHOULD be sent
using the TTL indicated in the "ttl" parameter, or with a
TTL of 1 if that parameter is not present. For
robustness, responses MUST be sent to the address
indicated in the "maddr" parameter even if it is not a
multicast address.

- If the second Via header field does not contain a "maddr"

parameter and is a receiver-tagged field (Section
6.40.2), send the message to the address in the
"received" parameter, using the port indicated in the
"sent-by" value, or using port 5060 if none is present.

- If neither of the previous cases apply, send the message

to the address indicated by the "sent-by" value in the
second Via header field.

6.40.4. User Agent and Redirect Servers

A UAS or redirect server sends a response based on one of the

following rules:

• If the first Via header field in the request contains a "maddr"

parameter, send the response to the multicast address listed
there, using the port indicated in "sent-by", or port 5060 if none
is present. The response SHOULD be sent using the TTL indicated
in the "ttl" parameter, or with a TTL of 1 if that parameter is not
 present. For robustness, responses MUST be sent to the address
indicated in the "maddr" parameter even if it is not a multicast
address.
• If the address in the "sent-by" value of the first Via field differs
from the source address of the packet, send the response to the
actual packet source address, similar to the treatment for
receiver-tagged Via header fields (Section 6.40.2).
• If neither of these conditions is true, send the response to the
address contained in the "sent-by" value. If the request was sent
using TCP, use the existing TCP connection if available.

6.40.5. Syntax

The format for a Via header field is shown in Fig. 11. The defaults for
"protocol-name" and "transport" are "SIP" and "UDP", respectively. The
"maddr" parameter, designating the multicast address, and the "ttl"
parameter, designating the time-to-live (TTL) value, are included only if
the request was sent via multicast. The "received" parameter is added
only for receiver-added Via fields (Section 6.40.2). For reasons of
privacy, a client or proxy may wish to hide its Via information by
encrypting it (see Section 6.22). The "hidden" parameter is included if
this header field was hidden by the upstream proxy (see 6.22). Note
that privacy of the proxy relies on the cooperation of the next hop, as
the next-hop proxy will, by necessity, know the IP address and port
number of the source host.

The "branch" parameter is included by every forking proxy. The token

MUST be unique for each distinct request generated when a proxy
forks. CANCEL requests MUST have the same branch value as the
corresponding forked request. When a response arrives at the proxy it
can use the branch value to figure out which branch the response
corresponds to. A proxy which generates a single request (non- forking)
MAY also insert the "branch" parameter. The identifier has to be unique
only within a set of isomorphic requests.

Via: SIP/2.0/UDP first.example.com:4000;ttl=16

;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example)
Via: SIP/2.0/UDP adk8
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 := ( host [ ":" port ] ) | ( concealed-host )
concealed-host := token
ttl := 1*3DIGIT
Figure 11: Syntax of Via header field

6.41. Warning

The Warning response-header field is used to carry additional

information about the status of a response. Warning headers are sent
with responses and have the 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 name or
pseudonym of the server adding the Warning header, for use in
debugging
warn-text := quoted-string

A response MAY carry more than one Warning header.

The "warn-text" should be in a natural language that is most likely to

be intelligible to the human user receiving the response. This decision
can be based on any available knowledge, such as the location of the
cache or user, the Accept-Language field in a request, or the Content-
Language field in a response. The default language is i-default [31].

Any server MAY add Warning headers to a 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 MUST NOT delete any Warning header field that it received with
a response.

When multiple Warning headers are attached to a response, the user

agent SHOULD display as many of them as possible, in the order that
they appear in the response. If it is not possible to display all of the
warnings, the user agent first displays warnings that appear early in
the response.
The warn-code consists of three digits. A first digit of "3" indicates
warnings specific to SIP.

This is a list of the currently-defined "warn-code"s, each with a

recommended warn-text in English, and a description of its meaning.
Note that these warnings describe failures induced by the session
description.

Warnings 300 through 329 are reserved for indicating problems with
keywords in the session description, 330 through 339 are warnings
related to basic network services requested in the session description,
370 through 379 are warnings related to quantitative QoS parameters
requested in the session description, and 390 through 399 are
miscellaneous warnings that do not fall into one of the above
categories.

300 Incompatible network protocol: One or more network protocols

contained in the session description are not available.

301 Incompatible network address formats: One or more network address

formats contained in the session description are not available.

302 Incompatible transport protocol: One or more transport protocols

described in the session description are not available.

303 Incompatible bandwidth units: One or more bandwidth measurement

units contained in the session description were not understood.

304 Media type not available: One or more media types contained in
the session description are not available.

305 Incompatible media format: One or more media formats contained in

the session description are not available.

306 Attribute not understood: One or more of the media attributes in

the session description are not supported.

307 Session description parameter not understood: A parameter other

than those listed above was not understood.

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

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

370 Insufficient bandwidth: The bandwidth specified in the session

description or defined by the media exceeds that known to be
available.

399 Miscellaneous warning: The warning text can include arbitrary

information to be presented to a 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.

Additional "warn-code"s, as in the example below, can be defined

through IANA.

Examples:

Warning: 307 isi.edu "Session parameter 'foo' not understood"

Warning: 301 isi.edu "Incompatible network address type 'E.164'"

6.42. WWW-Authenticate

The WWW-Authenticate response-header field MUST be included in 401

(Unauthorized) response messages. The field value consists of at least
one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI. See [H14.46] for a definition
of the syntax, and section 14 for an overview of usage.

The content of the "realm" parameter SHOULD be displayed to the

user. A user agent SHOULD cache the authorization credentials for a
given value of the destination (To header) and "realm" and attempt to
re- use these values on the next request for that destination.

In addition to the "basic" and "digest" authentication schemes defined

in the specifications cited above, SIP defines a new scheme, PGP (RFC
2015prop, [32]), Section 15. Other schemes, such as S/MIME, are for
further study.

ZVON > RFC Repository > RFC 2543

Frontpage / Contents
Prev | Next | RFC index | RFC search

Related sites:
• TopXML - XML Tutorials, • Planet Source • XML/XSLT Forums -
MS.NET XML Tutorials Code - The Do you have a tough
• VisualBuilder.com - largest public XML or XSLT
Java, JSP, ASP, XML. source code Question? Ask it
scripting languages, ... database on the here.
Internet • ASPAlliance - The
• Web Design - #1 ASP.NET
• DevGuru - ADO, ASP,
WebMaster Community
CSS2, HTML, Javascript,
forums - web
JetSQL, VBScript, WML,
design, servers, • Scripts - Scripts
XML, ...
hosting, ...

• Your HTML
 Source - HTML
Tutorials
Nursing Home answering pigeon Web Hosting -
Postcard Printing
Abuse service forge AccuWebHosting.Com
management office
Call Center water softener internet phone
training UK cubicles
International Prepaid
123 Fast Loans HDTV Plasma Mobile Phones
Adoption Phones
VoIP, Internet Ecco shoes
Direct TV Home Value Sacramento real estate
Telefonie Mephisto shoes
remote backup world of warcraft distributed io Lawyers Color Laser Printer
VoIP
martin guitars Hosted Exchange Incorporate Detektei
Internettelefonie