20 Header Fields
The general syntax for header fields is covered in Section 7.3. This
section lists the full set of header fields along with notes on
syntax, meaning, and usage. Throughout this section, we use [HX.Y]
to refer to Section X.Y of the current HTTP/1.1 specification RFC
2616 . Examples of each header field are given.
Information about header fields in relation to methods and proxy
processing is summarized in Tables 2 and 3.
The "where" column describes the request and response types in which
the header field can be used. Values in this column are:
R: header field may only appear in requests;
r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response
codes with which the header field can be used;
c: header field is copied from the request to the response.
An empty entry in the "where" column indicates that the header
field may be present in all requests and responses.
The "proxy" column describes the operations a proxy may perform on a
a: A proxy can add or concatenate the header field if not present.
m: A proxy can modify an existing header field value.
d: A proxy can delete a header field value.
r: A proxy must be able to read the header field, and thus this
header field cannot be encrypted.
The next six columns relate to the presence of a header field in a
c: Conditional; requirements on the header field depend on the
context of the message.
m: The header field is mandatory.
m*: The header field SHOULD be sent, but clients/servers need to
be prepared to receive messages without that header field.
o: The header field is optional.
t: The header field SHOULD be sent, but clients/servers need to be
prepared to receive messages without that header field.
If a stream-based protocol (such as TCP) is used as a
transport, then the header field MUST be sent.
*: The header field is required if the message body is not empty.
See Sections 20.14, 20.15 and 7.4 for details.
-: The header field is not applicable.
"Optional" means that an element 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 (The exception to this rule is the Require
header field discussed in 20.32). A "mandatory" 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 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 field in the
response, and the UAC MUST ignore the header field in the response.
A UA SHOULD ignore extension header parameters that are not
A compact form of some common header field names is also defined for
use when overall message size is an issue.
The Contact, From, and To header fields contain a URI. If the URI
contains a comma, question mark or semicolon, the URI MUST be
enclosed in angle brackets (< and >). Any URI parameters are
contained within these brackets. If the URI is not enclosed in angle
brackets, any semicolon-delimited parameters are header-parameters,
not URI parameters.
The Accept header field follows the syntax defined in [H14.1]. The
semantics are also identical, with the exception that if no Accept
header field is present, the server SHOULD assume a default value of
An empty Accept header field means that no formats are acceptable.
Header field where proxy ACK BYE CAN INV OPT REG
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c
Alert-Info R ar - - - o - -
Alert-Info 180 ar - - - o - -
Allow R - o - o o o
Allow 2xx - o - m* m* o
Allow r - o - o o o
Allow 405 - m - m m m
Authentication-Info 2xx - o - o o o
Authorization R o o o o o o
Call-ID c r m m m m m m
Call-Info ar - - - o o o
Contact R o - - m o o
Contact 1xx - - - o - -
Contact 2xx - - - m o o
Contact 3xx d - o - o o o
Contact 485 - o - o o o
Content-Disposition o o - o o o
Content-Encoding o o - o o o
Content-Language o o - o o o
Content-Length ar t t t t t t
Content-Type * * - * * *
CSeq c r m m m m m m
Date a o o o o o o
Error-Info 300-699 a - o o o o o
Expires - - - o - o
From c r m m m m m m
In-Reply-To R - - - o - -
Max-Forwards R amr m m m m m m
Min-Expires 423 - - - - - m
MIME-Version o o - o o o
Organization ar - - - o o o
Table 2: Summary of header fields, A--O
Header field where proxy ACK BYE CAN INV OPT REG
Priority R ar - - - o - -
Proxy-Authenticate 407 ar - m - m m m
Proxy-Authenticate 401 ar - o o o o o
Proxy-Authorization R dr o o - o o o
Proxy-Require R ar - o - o o o
Record-Route R ar o o o o o -
Record-Route 2xx,18x mr - o o o o -
Reply-To - - - o - -
Require ar - c - c c c
Retry-After 404,413,480,486 - o o o o o
500,503 - o o o o o
600,603 - o o o o o
Route R adr c c c c c c
Server r - o o o o o
Subject R - - - o - -
Supported R - o o m* o o
Supported 2xx - o o m* m* o
Timestamp o o o o o o
To c(1) r m m m m m m
Unsupported 420 - m - m m m
User-Agent o o o o o o
Via R amr m m m m m m
Via rc dr m m m m m m
Warning r - o o o o o
WWW-Authenticate 401 ar - m - m m m
WWW-Authenticate 407 ar - o - o o o
Table 3: Summary of header fields, P--Z; (1): copied with possible
addition of tag
Accept: application/sdp;level=1, application/x-private, text/html
The Accept-Encoding header field is similar to Accept, but restricts
the content-codings [H3.5] that are acceptable in the response. See
[H14.3]. The semantics in SIP are identical to those defined in
An empty Accept-Encoding header field is permissible. It is
equivalent to Accept-Encoding: identity, that is, only the identity
encoding, meaning no encoding, is permissible.
If no Accept-Encoding header field is present, the server SHOULD
assume a default value of identity.
This differs slightly from the HTTP definition, which indicates that
when not present, any encoding can be used, but the identity encoding
The Accept-Language header field is used in requests to indicate the
preferred languages for reason phrases, session descriptions, or
status responses carried as message bodies in the response. If no
Accept-Language header field is present, the server SHOULD assume all
languages are acceptable to the client.
The Accept-Language header field follows the syntax defined in
[H14.4]. The rules for ordering the languages based on the "q"
parameter apply to SIP as well.
Accept-Language: da, en-gb;q=0.8, en;q=0.7
When present in an INVITE request, the Alert-Info header field
specifies an alternative ring tone to the UAS. When present in a 180
(Ringing) response, the Alert-Info header field specifies an
alternative ringback tone to the UAC. A typical usage is for a proxy
to insert this header field to provide a distinctive ring feature.
The Alert-Info header field can introduce security risks. These
risks and the ways to handle them are discussed in Section 20.9,
which discusses the Call-Info header field since the risks are
In addition, a user SHOULD be able to disable this feature
This helps prevent disruptions that could result from the use of
this header field by untrusted elements.
The Allow header field lists the set of methods supported by the UA
generating the message.
All methods, including ACK and CANCEL, understood by the UA MUST be
included in the list of methods in the Allow header field, when
present. The absence of an Allow header field MUST NOT be
interpreted to mean that the UA sending the message supports no
methods. Rather, it implies that the UA is not providing any
information on what methods it supports.
Supplying an Allow header field in responses to methods other than
OPTIONS reduces the number of messages needed.
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
The Authentication-Info header field provides for mutual
authentication with HTTP Digest. A UAS MAY include this header field
in a 2xx response to a request that was successfully authenticated
using digest based on the Authorization header field.
Syntax and semantics follow those specified in RFC 2617 .
The Authorization header field contains authentication credentials of
a UA. Section 22.2 overviews the use of the Authorization header
field, and Section 22.4 describes the syntax and semantics when used
with HTTP authentication.
This header field, along with Proxy-Authorization, breaks the general
rules about multiple header field values. Although not a comma-
separated list, this header field name may be present multiple times,
and MUST NOT be combined into a single header line using the usual
rules described in Section 7.3.
In the example below, there are no quotes around the Digest
Authorization: Digest username="Alice", realm="atlanta.com",
The Call-ID header field uniquely identifies a particular invitation
or all registrations of a particular client. A single multimedia
conference can give rise to several calls with different Call-IDs,
for example, if a user invites a single individual several times to
the same (long-running) conference. Call-IDs are case-sensitive and
are simply compared byte-by-byte.
The compact form of the Call-ID header field is i.
The Call-Info 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. The "icon" parameter designates an image suitable as an
iconic representation of the caller or callee. The "info" parameter
describes the caller or callee in general, for example, through a web
page. The "card" parameter provides a business card, for example, in
vCard  or LDIF  formats. Additional tokens can be registered
using IANA and the procedures in Section 27.
Use of the Call-Info header field can pose a security risk. If a
callee fetches the URIs provided by a malicious caller, the callee
may be at risk for displaying inappropriate or offensive content,
dangerous or illegal content, and so on. Therefore, it is
RECOMMENDED that a UA only render the information in the Call-Info
header field if it can verify the authenticity of the element that
originated the header field and trusts that element. This need not
be the peer UA; a proxy can insert this header field into requests.
Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
A Contact header field value provides a URI whose meaning depends on
the type of request or response it is in.
A Contact header field value can contain a display name, a URI with
URI parameters, and header parameters.
This document defines the Contact parameters "q" and "expires".
These parameters are only used when the Contact is present in a
REGISTER request or response, or in a 3xx response. Additional
parameters may be defined in other specifications.
When the header field value contains a display name, the URI
including all URI parameters is enclosed in "<" and ">". If no "<"
and ">" are present, all parameters after the URI are header
parameters, not URI parameters. The display name can be tokens, or a
quoted string, if a larger character set is desired.
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. There may or may not be LWS between the display-name and the
These rules for parsing a display name, URI and URI parameters, and
header parameters also apply for the header fields To and From.
The Contact header field has a role similar to the Location header
field in HTTP. However, the HTTP header field 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 compact form of the Contact header field is m (for "moved").
Contact: "Mr. Watson" <sip:email@example.com>
"Mr. Watson" <mailto:firstname.lastname@example.org> ;q=0.1
The Content-Disposition header field describes how the message body
or, for multipart messages, a message body part is to be interpreted
by the UAC or UAS. This SIP header field extends the MIME Content-
Type (RFC 2183 ).
Several new "disposition-types" of the Content-Disposition header are
defined by SIP. 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. Note that the value "render" is used
rather than "inline" to avoid the connotation that the MIME body is
displayed as a part of the rendering of the entire message (since the
MIME bodies of SIP messages oftentimes are not displayed to users).
For backward-compatibility, if the Content-Disposition header field
is missing, the server SHOULD assume bodies of Content-Type
application/sdp are the disposition "session", while other content
types are "render".
The disposition type "icon" indicates that the body part contains an
image suitable as an iconic representation of the caller or callee
that could be rendered informationally by a user agent when a message
has been received, or persistently while a dialog takes place. The
value "alert" indicates that the body part contains information, such
as an audio clip, that should be rendered by the user agent in an
attempt to alert the user to the receipt of a request, generally a
request that initiates a dialog; this alerting body could for example
be rendered as a ring tone for a phone call after a 180 Ringing
provisional response has been sent.
Any MIME body with a "disposition-type" that renders content to the
user should only be processed when a message has been properly
The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, the
value "required" SHOULD be assumed. The handling parameter is
described in RFC 3204 .
If this header field is missing, the MIME type determines the default
content disposition. If there is none, "render" is assumed.
The Content-Encoding 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-body, the
content codings MUST be listed in the order in which they were
All content-coding values are case-insensitive. 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. A
server MAY apply content encodings to the bodies in responses. The
server MUST only use encodings listed in the Accept-Encoding header
field in the request.
The compact form of the Content-Encoding header field is e.
See [H14.12]. Example:
The Content-Length header field indicates the size of the message-
body, in decimal number of octets, sent to the recipient.
Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity. If a stream-based protocol (such as TCP) is used as
transport, the header field MUST be used.
The size of the message-body does not include the CRLF separating
header fields and body. 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 value MUST be set to zero.
The ability to omit Content-Length simplifies the creation of
cgi-like scripts that dynamically generate responses.
The compact form of the header field is l.
The Content-Type 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 field MUST be present if
the body is not empty. If the body is empty, and a Content-Type
header field is present, it indicates that the body of the specific
type has zero length (for example, an empty audio file).
The compact form of the header field is c.
c: text/html; charset=ISO-8859-4
A CSeq header field in a request contains a single decimal sequence
number and the request method. The sequence number MUST be
expressible as a 32-bit unsigned integer. The method part of CSeq is
case-sensitive. The CSeq header field serves to order transactions
within a dialog, to provide a means to uniquely identify
transactions, and to differentiate between new requests and request
retransmissions. Two CSeq header fields are considered equal if the
sequence number and the request method are identical. Example:
CSeq: 4711 INVITE
The Date header field contains the date and time. Unlike HTTP/1.1,
SIP only supports the most recent RFC 1123  format for dates. As
in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while
RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive.
The Date header field reflects the time when the request or response
is first sent.
The Date header field can be used by simple end systems without a
battery-backed clock to acquire a notion of current time.
However, in its GMT form, it requires clients to know their offset
Date: Sat, 13 Nov 2010 23:29:00 GMT
The Error-Info header field provides a pointer to additional
information about the error status response.
SIP UACs have user interface capabilities ranging from pop-up
windows and audio on PC softclients to audio-only on "black"
phones or endpoints connected via gateways. Rather than forcing a
server generating an error to choose between sending an error
status code with a detailed reason phrase and playing an audio
recording, the Error-Info header field allows both to be sent.
The UAC then has the choice of which error indicator to render to
A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if
it were a Contact in a redirect and generate a new INVITE, resulting
in a recorded announcement session being established. A non-SIP URI
MAY be rendered to the user.
SIP/2.0 404 The number you have dialed is not in service
The Expires header field gives the relative time after which the
message (or content) expires.
The precise meaning of this is method dependent.
The expiration time in an INVITE does not affect the duration of the
actual session that may result from the invitation. Session
description protocols may offer the ability to express time limits on
the session duration, however.
The value of this field is an integral number of seconds (in decimal)
between 0 and (2**32)-1, measured from the receipt of the request.
The From header field indicates the initiator of the request. This
may be different from the initiator of the dialog. Requests sent by
the callee to the caller use the callee's address in the From header
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. 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. Syntax issues are
discussed in Section 7.3.1.
Two From header fields are equivalent if their URIs match, and their
parameters match. Extension parameters in one header field, not
present in the other are ignored for the purposes of comparison. This
means that the display name and presence or absence of angle brackets
do not affect matching.
See Section 20.10 for the rules for parsing a display name, URI and
URI parameters, and header field parameters.
The compact form of the From header field is f.
From: "A. G. Bell" <sip:email@example.com> ;tag=a48s
f: Anonymous <sip:firstname.lastname@example.org>;tag=hyh8
The In-Reply-To header field enumerates the Call-IDs that this call
references or returns. These Call-IDs may have been cached by the
client then included in this header field in a return call.
This allows automatic call distribution systems to route return
calls to the originator of the first call. This also allows
callees to filter calls, so that only return calls for calls they
originated will be accepted. This field is not a substitute for
In-Reply-To: email@example.com, firstname.lastname@example.org
The Max-Forwards header field must 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 that appears to be
failing or looping in mid-chain.
The Max-Forwards value is an integer in the range 0-255 indicating
the remaining number of times this request message is allowed to be
forwarded. This count is decremented by each server that forwards
the request. The recommended initial value is 70.
This header field should be inserted by elements that can not
otherwise guarantee loop detection. For example, a B2BUA should
insert a Max-Forwards header field.
The Min-Expires header field conveys the minimum refresh interval
supported for soft-state elements managed by that server. This
includes Contact header fields that are stored by a registrar. The
header field contains a decimal integer number of seconds from 0 to
(2**32)-1. The use of the header field in a 423 (Interval Too Brief)
response is described in Sections 10.2.8, 10.3, and 21.4.17.
The Organization header field conveys the name of the organization to
which the SIP element issuing the request or response belongs.
The field MAY be used by client software to filter calls.
Organization: Boxes by Bob
The Priority header field indicates the urgency of the request as
perceived by the client. The Priority header field describes the
priority that the SIP request should have to the receiving human or
its agent. For example, it may be factored into decisions about call
routing and acceptance. For these decisions, a message containing no
Priority header field SHOULD be treated as if it specified a Priority
of "normal". The Priority header field does not influence the use of
communications resources such as packet forwarding priority in
routers or access to circuits in PSTN gateways. The header field can
have the values "non-urgent", "normal", "urgent", and "emergency",
but additional values can be defined elsewhere. It is RECOMMENDED
that the value of "emergency" only be used when life, limb, or
property are in imminent danger. Otherwise, there are no semantics
defined for this header field.
These are the values of RFC 2076 , with the addition of
Subject: A tornado is heading our way!
Subject: Weekend plans
A Proxy-Authenticate header field value contains an authentication
The use of this header field is defined in [H14.33]. See Section22.3 for further details on its usage.
Proxy-Authenticate: Digest realm="atlanta.com",
opaque="", stale=FALSE, algorithm=MD5
The Proxy-Authorization header field allows the client to identify
itself (or its user) to a proxy that requires authentication. A
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.
See Section 22.3 for a definition of the usage of this header field.
This header field, along with Authorization, breaks the general rules
about multiple header field names. Although not a comma-separated
list, this header field name may be present multiple times, and MUST
NOT be combined into a single header line using the usual rules
described in Section 7.3.1.
Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
The Proxy-Require header field is used to indicate proxy-sensitive
features that must be supported by the proxy. See Section 20.32 for
more details on the mechanics of this message and a usage example.
The Record-Route header field is inserted by proxies in a request to
force future requests in the dialog to be routed through the proxy.
Examples of its use with the Route header field are described in
The Reply-To header field contains a logical return URI that may be
different from the From header field. For example, the URI MAY be
used to return missed calls or unestablished sessions. If the user
wished to remain anonymous, the header field SHOULD either be omitted
from the request or populated in such a way that does not reveal any
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. Syntax issues are discussed in Section 7.3.1.
Reply-To: Bob <sip:email@example.com>
The Require header field is used by UACs to tell UASs about options
that the UAC expects the UAS to support in order to process the
request. Although an optional header field, the Require MUST NOT be
ignored if it is present.
The Require header field contains a list of option tags, described in
Section 19.2. Each option tag defines a SIP extension that MUST be
understood to process the request. Frequently, this is used to
indicate that a specific set of extension header fields need to be
understood. A UAC compliant to this specification MUST only include
option tags corresponding to standards-track RFCs.
The Retry-After header field can be used with a 500 (Server Internal
Error) or 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), 413 (Request Entity Too Large), 480
(Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603
(Decline) response to indicate when the called party anticipates
being available again. The value of this field is a positive integer
number of seconds (in decimal) after the time of the response.
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: 120 (I'm in a meeting)
The Route header field is used to force routing for a request through
the listed set of proxies. Examples of the use of the Route header
field are in Section 16.12.1.
The Server header field contains information about the software used
by the UAS to handle the request.
Revealing the specific software version of the server might allow the
server to become more vulnerable to attacks against software that is
known to contain security holes. Implementers SHOULD make the Server
header field a configurable option.
Server: HomeServer v2
The Subject header field provides a summary or indicates the nature
of the call, allowing call filtering without having to parse the
session description. The session description does not have to use
the same subject indication as the invitation.
The compact form of the Subject header field is s.
Subject: Need more boxes
s: Tech Support
The Supported header field enumerates all the extensions supported by
the UAC or UAS.
The Supported header field contains a list of option tags, described
in Section 19.2, that are understood by the UAC or UAS. A UA
compliant to this specification MUST only include option tags
corresponding to standards-track RFCs. If empty, it means that no
extensions are supported.
The compact form of the Supported header field is k.
The Timestamp header field describes when the UAC sent the request to
See Section 8.2.6 for details on how to generate a response to a
request that contains the header field. Although there is no
normative behavior defined here that makes use of the header, it
allows for extensions or SIP applications to obtain RTT estimates.
The To header field specifies the logical recipient of the request.
The optional "display-name" is meant to be rendered by a human-user
interface. The "tag" parameter serves as a general mechanism for
See Section 19.3 for details of the "tag" parameter.
Comparison of To header fields for equality is identical to
comparison of From header fields. See Section 20.10 for the rules
for parsing a display name, URI and URI parameters, and header field
The compact form of the To header field is t.
The following are examples of valid To header fields:
To: The Operator <sip:firstname.lastname@example.org>;tag=287447
The Unsupported header field lists the features not supported by the
UAS. See Section 20.32 for motivation.
The User-Agent header field contains information about the UAC
originating the request. The semantics of this header field are
defined in [H14.43].
Revealing the specific software version of the user agent might allow
the user agent to become more vulnerable to attacks against software
that is known to contain security holes. Implementers SHOULD make
the User-Agent header field a configurable option.
User-Agent: Softphone Beta1.5
The Via header field indicates the path taken by the request so far
and indicates the path that should be followed in routing responses.
The branch ID parameter in the Via header field values serves as a
transaction identifier, and is used by proxies to detect loops.
A Via header field value contains the transport protocol used to send
the message, the client's host name or network address, and possibly
the port number at which it wishes to receive responses. A Via
header field value can also contain parameters such as "maddr",
"ttl", "received", and "branch", whose meaning and use are described
in other sections. For implementations compliant to this
specification, the value of the branch parameter MUST start with the
magic cookie "z9hG4bK", as discussed in Section 18.104.22.168.
Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
"TLS" means TLS over TCP. When a request is sent to a SIPS URI, the
protocol still indicates "SIP", and the transport protocol is TLS.
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
The compact form of the Via header field is v.
In this example, the message originated from a multi-homed host with
two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong
as to which network interface would be used. Erlang.bell-
telephone.com noticed the mismatch and added a parameter to the
previous hop's Via header field value, containing the address that
the packet actually came from.
The host or network address and port number are not required to
follow the SIP URI syntax. Specifically, LWS on either side of the
":" or "/" is allowed, as shown here:
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
Even though this specification mandates that the branch parameter be
present in all requests, the BNF for the header field indicates that
it is optional. This allows interoperation with RFC 2543 elements,
which did not have to insert the branch parameter.
Two Via header fields are equal if their sent-protocol and sent-by
fields are equal, both have the same set of parameters, and the
values of all parameters are equal.
The Warning header field is used to carry additional information
about the status of a response. Warning header field values are sent
with responses and contain a three-digit warning code, host name, and
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 user, the Accept-Language field in a request, or the
Content-Language field in a response. The default language is i-
The currently-defined "warn-code"s are listed below, with a
recommended warn-text in English and a description of their meaning.
These warnings describe failures induced by the session description.
The first digit of warning codes beginning with "3" indicates
warnings specific to SIP. 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 descriptionSIP, 370 through 379 are warnings related to
quantitative QoS parameters requested in the session description, and
390380 through 399 are miscellaneous SIP-related 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
302 Incompatible transport protocol: One or more transport
protocols described in the session description are not
303 Incompatible bandwidth units: One or more bandwidth
measurement units contained in the session description were
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
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
1xx and 2xx have been taken by HTTP/1.1.
Additional "warn-code"s can be defined through IANA, as defined in
Warning: 307 isi.edu "Session parameter 'foo' not understood"
Warning: 301 isi.edu "Incompatible network address type 'E.164'"
A WWW-Authenticate header field value contains an authentication
challenge. See Section 22.2 for further details on its usage.
WWW-Authenticate: Digest realm="atlanta.com",
opaque="", stale=FALSE, algorithm=MD5