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: (RFC2368, [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 RFC1123 [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 RFC822 [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 RFC2076 [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:
o 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.
o 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).
o If neither of these conditions is true, send the response to
the address contained in the "sent-by" value. If the request