toplabel = alpha | alpha *( alphanum | "-" ) alphanum
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit
url-parameters = *( ";" url-parameter )
url-parameter = transport-param | user-param | method-param
| ttl-param | maddr-param | other-param
transport-param = "transport=" ( "udp" | "tcp" )
ttl-param = "ttl=" ttl
ttl = 1*3DIGIT ; 0 to 255
maddr-param = "maddr=" host
user-param = "user=" ( "phone" | "ip" )
method-param = "method=" Method
tag-param = "tag=" UUID
UUID = 1*( hex | "-" )
other-param = ( token | ( token "=" ( token | quoted-string )))
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = 1*uric
hvalue = *uric
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
digits = 1*DIGIT
Figure 3: SIP URL syntax
The URI character classes referenced above are described in Appendix
C.
The components of the SIP URI have the following meanings.
telephone-subscriber = global-phone-number | local-phone-number
global-phone-number = "+" 1*phonedigit [isdn-subaddress]
[post-dial]
local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress]
[post-dial]
isdn-subaddress = ";isub=" 1*phonedigit
post-dial = ";postd=" 1*(phonedigit | dtmf-digit
| pause-character)
phonedigit = DIGIT | visual-separator
visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-tone
one-second-pause = "p"
wait-for-dial-tone = "w"
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D"
Figure 4: SIP URL syntax; telephone subscriber
user: If the host is an Internet telephony gateway, the user field
MAY also encode a telephone number using the notation of
telephone-subscriber (Fig. 4). The telephone number is a special
case of a user name and cannot be distinguished by a BNF. Thus,
a URL parameter, user, is added to distinguish telephone numbers
from user names. The phone identifier is to be used when
connecting to a telephony gateway. Even without this parameter,
recipients of SIP URLs MAY interpret the pre-@ part as a phone
number if local restrictions on the name space for user name
allow it.
password: The SIP scheme MAY use the format "user:password" in the
userinfo field. The use of passwords in the userinfo is NOT
RECOMMENDED, because the passing of authentication information
in clear text (such as URIs) has proven to be a security risk in
almost every case where it has been used.
host: The mailto: URL and RFC822 email addresses require that
numeric host addresses ("host numbers") are enclosed in square
brackets (presumably, since host names might be numeric), while
host numbers without brackets are used for all other URLs. The
SIP URL requires the latter form, without brackets.
The issue of IPv6 literal addresses in URLs is being looked at
elsewhere in the IETF. SIP implementers are advised to keep up to
date on that activity.
port: The port number to send a request to. If not present, the
procedures outlined in Section 1.4.2 are used to determine the
port number to send a request to.
URL parameters: SIP URLs can define specific parameters of the
request. URL parameters are added after the host component and
are separated by semi-colons. The transport parameter determines
the the transport mechanism (UDP or TCP). UDP is to be assumed
when no explicit transport parameter is included. The maddr
parameter provides the server address to be contacted for this
user, overriding the address supplied in the host field. This
address is typically a multicast address, but could also be the
address of a backup server. The ttl parameter determines the
time-to-live value of the UDP multicast packet and MUST only be
used if maddr is a multicast address and the transport protocol
is UDP. The user parameter was described above. For example, to
specify to call j.doe@big.com using multicast to 239.255.255.1
with a ttl of 15, the following URL would be used:
sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
The transport, maddr, and ttl parameters MUST NOT be used in the From
and To header fields and the Request-URI; they are ignored if
present.
Headers: Headers of the SIP request can be defined with the "?"
mechanism within a SIP URL. The special hname "body" indicates
that the associated hvalue is the message-body of the SIP INVITE
request. Headers MUST NOT be used in the From and To header
fields and the Request-URI; they are ignored if present. hname
and hvalue are encodings of a SIP header name and value,
respectively. All URL reserved characters in the header names
and values MUST be escaped.
Method: The method of the SIP request can be specified with the
method parameter. This parameter MUST NOT be used in the From
and To header fields and the Request-URI; they are ignored if
present.
Table 2 summarizes where the components of the SIP URL can be used
and what default values they assume if not present.
Examples of SIP URLs are:
default Req.-URI To From Contact external
user -- x x x x x
password -- x x x x
host mandatory x x x x x
port 5060 x x x x x
user-param ip x x x x x
method INVITE x x
maddr-param -- x x
ttl-param 1 x x
transp.-param -- x x
headers -- x x
Table 2: Use and default values of URL components for SIP headers,
Request-URI and references
sip:j.doe@big.com
sip:j.doe:secret@big.com;transport=tcp
sip:j.doe@big.com?subject=project
sip:+1-212-555-1212:1234@gateway.com;user=phone
sip:1212@gateway.com
sip:alice@10.1.2.3
sip:alice@example.com
sip:alice%40example.com@gateway.com
sip:alice@registrar.com;method=REGISTER
Within a SIP message, URLs are used to indicate the source and
intended destination of a request, redirection addresses and the
current destination of a request. Normally all these fields will
contain SIP URLs.
SIP URLs are case-insensitive, so that for example the two URLs
sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All
URL parameters are included when comparing SIP URLs for equality.
SIP header fields MAY contain non-SIP URLs. As an example, if a call
from a telephone is relayed to the Internet via SIP, the SIP From
header field might contain a phone URL.
3 SIP Message Overview
SIP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC2279 [21]). Senders MUST terminate lines with a
CRLF, but receivers MUST also interpret CR and LF by themselves as
line terminators.
Except for the above difference in character sets, much of the
message syntax is and header fields are identical to HTTP/1.1; rather
than repeating the syntax and semantics here we use [HX.Y] to refer
to Section X.Y of the current HTTP/1.1 specification (RFC2068 [11]).
In addition, we describe SIP in both prose and an augmented Backus-
Naur form (ABNF). See section C for an overview of ABNF.
Note, however, that SIP is not an extension of HTTP.
Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
transactions can be carried in a single TCP connection or UDP
datagram. UDP datagrams, including all headers, SHOULD NOT be larger
than the path maximum transmission unit (MTU) if the MTU is known, or
1500 bytes if the MTU is unknown.
The 1500 bytes accommodates encapsulation within the
"typical" ethernet MTU without IP fragmentation. Recent
studies [22] indicate that an MTU of 1500 bytes is a
reasonable assumption. The next lower common MTU values are
1006 bytes for SLIP and 296 for low-delay PPP (RFC1191
[23]). Thus, another reasonable value would be a message
size of 950 bytes, to accommodate packet headers within the
SLIP MTU without fragmentation.
A SIP message is either a request from a client to a server, or a
response from a server to a client.
SIP-message = Request | Response
Both Request (section 4) and Response (section 5) messages use the
generic-message format of RFC822 [24] for transferring entities (the
body of the message). Both types of messages consist of a start-line,
one or more header fields (also known as "headers"), an empty line
(i.e., a line with nothing preceding the carriage-return line-feed
(CRLF)) indicating the end of the header fields, and an optional
message-body. To avoid confusion with similar-named headers in HTTP,
we refer to the headers describing the message body as entity
headers. These components are described in detail in the upcoming
sections.
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line | ;Section 4.1
Status-Line ;Section 5.1
message-header = ( general-header
| request-header
| response-header
| entity-header )
In the interest of robustness, any leading empty line(s) MUST be
ignored. In other words, if the Request or Response message begins
with one or more CRLF, CR, or LFs, these characters MUST be ignored.
4 Request
The Request message format is shown below:
Request = Request-Line ; Section 4.1
*( general-header
| request-header
| entity-header )
CRLF
[ message-body ] ; Section 8
4.1 Request-Line
The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence.
Request-Line = Method SP Request-URI SP SIP-Version CRLF
general-header = Accept ; Section 6.7
| Accept-Encoding ; Section 6.8
| Accept-Language ; Section 6.9
| Call-ID ; Section 6.12
| Contact ; Section 6.13
| CSeq ; Section 6.17
| Date ; Section 6.18
| Encryption ; Section 6.19
| Expires ; Section 6.20
| From ; Section 6.21
| Record-Route ; Section 6.29
| Timestamp ; Section 6.36
| To ; Section 6.37
| Via ; Section 6.40
entity-header = Content-Encoding ; Section 6.14
| Content-Length ; Section 6.15
| Content-Type ; Section 6.16
request-header = Authorization ; Section 6.11
| Contact ; Section 6.13
| Hide ; Section 6.22
| Max-Forwards ; Section 6.23
| Organization ; Section 6.24
| Priority ; Section 6.25
| Proxy-Authorization ; Section 6.27
| Proxy-Require ; Section 6.28
| Route ; Section 6.33
| Require ; Section 6.30
| Response-Key ; Section 6.31
| Subject ; Section 6.35
| User-Agent ; Section 6.39
response-header = Allow ; Section 6.10
| Proxy-Authenticate ; Section 6.26
| Retry-After ; Section 6.32
| Server ; Section 6.34
| Unsupported ; Section 6.38
| Warning ; Section 6.41
| WWW-Authenticate ; Section 6.42
Table 3: SIP headers
4.2 Methods
The methods are defined below. Methods that are not supported by a
proxy or redirect server are treated by that server as if they were
an OPTIONS method and forwarded accordingly. Methods that are not
supported by a user agent server or registrar cause a 501 (Not
Implemented) response to be returned (Section 7). As in HTTP, the
Method token is case-sensitive.
Method = "INVITE" | "ACK" | "OPTIONS" | "BYE"
| "CANCEL" | "REGISTER"
4.2.1 INVITE
The INVITE method indicates that the user or service is being invited
to participate in a session. The message body contains a description
of the session to which the callee is being invited. For two-party
calls, the caller indicates the type of media it is able to receive
and possibly the media it is willing to send as well as their
parameters such as network destination. A success response MUST
indicate in its message body which media the callee wishes to receive
and MAY indicate the media the callee is going to send.
Not all session description formats have the ability to
indicate sending media.
A server MAY automatically respond to an invitation for a conference
the user is already participating in, identified either by the SIP
Call-ID or a globally unique identifier within the session
description, with a 200 (OK) response.
If a user agent receives an INVITE request for an existing call leg
with a higher CSeq sequence number than any previous INVITE for the
same Call-ID, it MUST check any version identifiers in the session
description or, if there are no version identifiers, the content of
the session description to see if it has changed. It MUST also
inspect any other header fields for changes. If there is a change,
the user agent MUST update any internal state or information
generated as a result of that header. If the session description has
changed, the user agent server MUST adjust the session parameters
accordingly, possibly after asking the user for confirmation.
(Versioning of the session description can be used to accommodate the
capabilities of new arrivals to a conference, add or delete media or
change from a unicast to a multicast conference.)
This method MUST be supported by SIP proxy, redirect and user agent
servers as well as clients.
4.2.2 ACK
The ACK request confirms that the client has received a final
response to an INVITE request. (ACK is used only with INVITE
requests.) 2xx responses are acknowledged by client user agents, all
other final responses by the first proxy or client user agent to
receive the response. The Via is always initialized to the host that
originates the ACK request, i.e., the client user agent after a 2xx
response or the first proxy to receive a non-2xx final response. The
ACK request is forwarded as the corresponding INVITE request, based
on its Request-URI. See Section 10 for details.
The ACK request MAY contain a message body with the final session
description to be used by the callee. If the ACK message body is
empty, the callee uses the session description in the INVITE request.
A proxy server receiving an ACK request after having sent a 3xx, 4xx,
5xx, or 6xx response must make a determination about whether the ACK
is for it, or for some user agent or proxy server further downstream.
This determination is made by examining the tag in the To field. If
the tag in the ACK To header field matches the tag in the To header
field of the response, and the From, CSeq and Call-ID header fields
in the response match those in the ACK, the ACK is meant for the
proxy server. Otherwise, the ACK SHOULD be proxied downstream as any
other request.
It is possible for a user agent client or proxy server to
receive multiple 3xx, 4xx, 5xx, and 6xx responses to a
request along a single branch. This can happen under
various error conditions, typically when a forking proxy
transitions from stateful to stateless before receiving all
responses. The various responses will all be identical,
except for the tag in the To field, which is different for
each one. It can therefore be used as a means to
disambiguate them.
This method MUST be supported by SIP proxy, redirect and user agent
servers as well as clients.
4.2.3 OPTIONS
The server is being queried as to its capabilities. A server that
believes it can contact the user, such as a user agent where the user
is logged in and has been recently active, MAY respond to this
request with a capability set. A called user agent MAY return a
status reflecting how it would have responded to an invitation, e.g.,
600 (Busy). Such a server SHOULD return an Allow header field
indicating the methods that it supports. Proxy and redirect servers
simply forward the request without indicating their capabilities.
This method MUST be supported by SIP proxy, redirect and user agent
servers, registrars and clients.
4.2.4 BYE
The user agent client uses BYE to indicate to the server that it
wishes to release the call. A BYE request is forwarded like an INVITE
request and MAY be issued by either caller or callee. A party to a
call SHOULD issue a BYE request before releasing a call ("hanging
up"). A party receiving a BYE request MUST cease transmitting media
streams specifically directed at the party issuing the BYE request.
If the INVITE request contained a Contact header, the callee SHOULD
send a BYE request to that address rather than the From address.
This method MUST be supported by proxy servers and SHOULD be
supported by redirect and user agent SIP servers.
4.2.5 CANCEL
The CANCEL request cancels a pending request with the same Call-ID,
To, From and CSeq (sequence number only) header field values, but
does not affect a completed request. (A request is considered
completed if the server has returned a final status response.)
A user agent client or proxy client MAY issue a CANCEL request at any
time. A proxy, in particular, MAY choose to send a CANCEL to
destinations that have not yet returned a final response after it has
received a 2xx or 6xx response for one or more of the parallel-search
requests. A proxy that receives a CANCEL request forwards the request
to all destinations with pending requests.
The Call-ID, To, the numeric part of CSeq and From headers in the
CANCEL request are identical to those in the original request. This
allows a CANCEL request to be matched with the request it cancels.
However, to allow the client to distinguish responses to the CANCEL
from those to the original request, the CSeq Method component is set
to CANCEL. The Via header field is initialized to the proxy issuing
the CANCEL request. (Thus, responses to this CANCEL request only
reach the issuing proxy.)
Once a user agent server has received a CANCEL, it MUST NOT issue a
2xx response for the cancelled original request.
A redirect or user agent server receiving a CANCEL request responds
with a status of 200 (OK) if the transaction exists and a status of
481 (Transaction Does Not Exist) if not, but takes no further action.
In particular, any existing call is unaffected.
The BYE request cannot be used to cancel branches of a
parallel search, since several branches may, through
intermediate proxies, find the same user agent server and
then terminate the call. To terminate a call instead of
just pending searches, the UAC must use BYE instead of or
in addition to CANCEL. While CANCEL can terminate any
pending request other than ACK or CANCEL, it is typically
useful only for INVITE. 200 responses to INVITE and 200
responses to CANCEL are distinguished by the method in the
Cseq header field, so there is no ambiguity.
This method MUST be supported by proxy servers and SHOULD be
supported by all other SIP server types.
4.2.6 REGISTER
A client uses the REGISTER method to register the address listed in
the To header field with a SIP server.
A user agent MAY register with a local server on startup by sending a
REGISTER request to the well-known "all SIP servers" multicast
address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped
to ensure it is not forwarded beyond the boundaries of the
administrative system. This MAY be done with either TTL or
administrative scopes [25], depending on what is implemented in the
network. SIP user agents MAY listen to that address and use it to
become aware of the location of other local users [20]; however, they
do not respond to the request. A user agent MAY also be configured
with the address of a registrar server to which it sends a REGISTER
request upon startup.
Requests are processed in the order received. Clients SHOULD avoid
sending a new registration (as opposed to a retransmission) until
they have received the response from the server for the previous one.
Clients may register from different locations, by necessity
using different Call-ID values. Thus, the CSeq value cannot
be used to enforce ordering. Since registrations are
additive, ordering is less of a problem than if each
REGISTER request completely replaced all earlier ones.
The meaning of the REGISTER request-header fields is defined as
follows. We define "address-of-record" as the SIP address that the
registry knows the registrand, typically of the form "user@domain"
rather than "user@host". In third-party registration, the entity
issuing the request is different from the entity being registered.
To: The To header field contains the address-of-record whose
registration is to be created or updated.
From: The From header field contains the address-of-record of the
person responsible for the registration. For first-party
registration, it is identical to the To header field value.
Request-URI: The Request-URI names the destination of the
registration request, i.e., the domain of the registrar. The
user name MUST be empty. Generally, the domains in the Request-
URI and the To header field have the same value; however, it is
possible to register as a "visitor", while maintaining one's
name. For example, a traveler sip:alice@acme.com (To) might
register under the Request-URI sip:atlanta.hiayh.org , with the
former as the To header field and the latter as the Request-URI.
The REGISTER request is no longer forwarded once it has reached
the server whose authoritative domain is the one listed in the
Request-URI.
Call-ID: All registrations from a client SHOULD use the same Call-ID
header value, at least within the same reboot cycle.
Cseq: Registrations with the same Call-ID MUST have increasing CSeq
header values. However, the server does not reject out-of-order
requests.
Contact: The request MAY contain a Contact header field; future non-
REGISTER requests for the URI given in the To header field
SHOULD be directed to the address(es) given in the Contact
header.
If the request does not contain a Contact header, the registration
remains unchanged.
This is useful to obtain the current list of registrations
in the response. Registrations using SIP URIs that differ
in one or more of host, port, transport-param or maddr-
param (see Figure 3) from an existing registration are
added to the list of registrations. Other URI types are
compared according to the standard URI equivalency rules
for the URI schema. If the URIs are equivalent to that of
an existing registration, the new registration replaces the
old one if it has a higher q value or, for the same value
of q, if the ttl value is higher. All current registrations
MUST share the same action value. Registrations that have
a different action than current registrations for the same
user MUST be rejected with status of 409 (Conflict).
A proxy server ignores the q parameter when processing non-REGISTER
requests, while a redirect server simply returns that parameter in
its Contact response header field.
Having the proxy server interpret the q parameter is not
sufficient to guide proxy behavior, as it is not clear, for
example, how long it is supposed to wait between trying
addresses.
If the registration is changed while a user agent or proxy server
processes an invitation, the new information SHOULD be used.
This allows a service known as "directed pick-up". In the
telephone network, directed pickup permits a user at a
remote station who hears his own phone ringing to pick up
at that station, dial an access code, and be connected to
the calling user as if he had answered his own phone.
A server MAY choose any duration for the registration lifetime.
Registrations not refreshed after this amount of time SHOULD be
silently discarded. Responses to a registration SHOULD include an
Expires header (Section 6.20) or expires Contact parameters (Section
6.13), indicating the time at which the server will drop the
registration. If none is present, one hour is assumed. Clients MAY
request a registration lifetime by indicating the time in an Expires
header in the request. A server SHOULD NOT use a higher lifetime than
the one requested, but MAY use a lower one. A single address (if
host-independent) MAY be registered from several different clients.
A client cancels an existing registration by sending a REGISTER
request with an expiration time (Expires) of zero seconds for a
particular Contact or the wildcard Contact designated by a "*" for
all registrations. Registrations are matched based on the user, host,
port and maddr parameters.
The server SHOULD return the current list of registrations in the 200
response as Contact header fields.
It is particularly important that REGISTER requests are authenticated
since they allow to redirect future requests (see Section 13.2).
Beyond its use as a simple location service, this method is
needed if there are several SIP servers on a single host.
In that case, only one of the servers can use the default
port number.
Support of this method is RECOMMENDED.
4.3 Request-URI
The Request-URI is a SIP URL as described in Section 2 or a general
URI. It indicates the user or service to which this request is being
addressed. Unlike the To field, the Request-URI MAY be re-written by
proxies.
When used as a Request-URI, a 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.
Typically, the UAC sets the Request-URI and To to the same
SIP URL, presumed to remain unchanged over long time
periods. However, if the UAC has cached a more direct path
to the callee, e.g., from the Contact header field of a
response to a previous request, the To would still contain
the long-term, "public" address, while the Request-URI
would be set to the cached address.
Proxy and redirect servers MAY use the information in the Request-URI
and request header fields to handle the request and possibly rewrite
the Request-URI. For example, a request addressed to the generic
address sip:sales@acme.com is proxied to the particular person, e.g.,
sip:bob@ny.acme.com , with the To field remaining as
sip:sales@acme.com. At ny.acme.com , Bob then designates Alice as
the temporary substitute.
The host part of the Request-URI typically agrees with one of the
host names of the receiving server. If it does not, the server SHOULD
proxy the request to the address indicated or return a 404 (Not
Found) response if it is unwilling or unable to do so. For example,
the Request-URI and server host name can disagree in the case of a
firewall proxy that handles outgoing calls. This mode of operation is
similar to that of HTTP proxies.
If a SIP server receives a request with a URI indicating a scheme
other than SIP which that server does not understand, the server MUST
return a 400 (Bad Request) response. It MUST do this even if the To
header field contains a scheme it does understand. This is because
proxies are responsible for processing the Request-URI; the To field
is of end-to-end significance.
4.3.1 SIP Version
Both request and response messages include the version of SIP in use,
and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced
by SIP/2.0) regarding version ordering, compliance requirements, and
upgrading of version numbers. To be compliant with this
specification, applications sending SIP messages MUST include a SIP-
Version of "SIP/2.0".
4.4 Option Tags
Option tags are unique identifiers used to designate new options in
SIP. These tags are used in Require (Section 6.30) and Unsupported
(Section 6.38) fields.
Syntax:
option-tag = token
See Section C for a definition of token. The creator of a new SIP
option MUST either prefix the option with their reverse domain name
or register the new option with the Internet Assigned Numbers
Authority (IANA). For example, "com.foo.mynewfeature" is an apt name
for a feature whose inventor can be reached at "foo.com". Individual
organizations are then responsible for ensuring that option names
don't collide. Options registered with IANA have the prefix
"org.iana.sip.", options described in RFCs have the prefix
"org.ietf.rfc.N", where N is the RFCnumber. Option tags are case-
insensitive.
4.4.1 Registering New Option Tags with IANA
When registering a new SIP option, the following information MUST be
provided:
o Name and description of option. The name MAY be of any
length, but SHOULD be no more than twenty characters long. The
name MUST consist of alphanum (See Figure 3) characters only;
o Indication of who has change control over the option (for
example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of
companies);
o A reference to a further description, if available, for
example (in order of preference) an RFC, a published paper, a
patent filing, a technical report, documented source code or a
computer manual;
o Contact information (postal and email address);
Registrations should be sent to iana@iana.org
This procedure has been borrowed from RTSP [4] and the RTP
AVP [26].
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 ; Section 5.1
*( general-header
| response-header
| entity-header )
CRLF
[ message-body ] ; Section 8
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 ;Fig. 5
| Success ;Fig. 5
| Redirection ;Fig. 6
| Client-Error ;Fig. 7
| Server-Error ;Fig. 8
| Global-Failure ;Fig. 9
| 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" ; Trying
| "180" ; Ringing
| "181" ; Call Is Being Forwarded
| "182" ; Queued
Success = "200" ; OK
Figure 5: Informational and success status codes
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" ; 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" ; 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" ; 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 RFC822 [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