RFC 2543
SIP: Session Initiation Protocol
2 SIP Uniform Resource Locators
SIP URLs are used within SIP messages to indicate the originator (From), current destination (Request-URI) and final recipient (To) of a SIP request, and to specify redirection addresses (Contact). A SIP URL can also be embedded in web pages or other hyperlinks to indicate that a particular user or service can be called via SIP. When used as a hyperlink, the SIP URL indicates the use of the INVITE method. The SIP URL scheme is defined to allow setting SIP request-header fields and the SIP message-body. This corresponds to the use of mailto: URLs. It makes it possible, for example, to specify the subject, urgency or media types of calls initiated through a web page or as part of an email message. A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax shown in Fig. 3. The syntax is described using Augmented Backus-Naur Form (See Section C). Note that reserved characters have to be escaped and that the "set of characters reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding" [12].
SIP-URL = "sip:" [ userinfo "@" ] hostport
url-parameters [ headers ]
userinfo = user [ ":" password ]
user = *( unreserved | escaped
| "&" | "=" | "+" | "$" | "," )
password = *( unreserved | escaped
| "&" | "=" | "+" | "$" | "," )
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
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 RFC 822 email addresses require that
numeric host addresses ("host numbers") are enclosed in square
brackets (presumably, since host names might be numeric), while
host numbers without brackets are used for all other URLs. The
SIP URL requires the latter form, without brackets.
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 (RFC 2279 [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 (RFC 2068 [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 (RFC 1191 [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 RFC 822 [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 RFC number. 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 RFC 822 [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.76.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#Method6.11 Authorization
A user agent that wishes to authenticate itself with a server -- usually, but not necessarily, after receiving a 401 response -- MAY do so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. Section 13.2 overviews the use of the Authorization header, and section 15 describes the syntax and semantics when used with PGP based authentication.
6.12 Call-ID
The Call-ID general-header field uniquely identifies a particular invitation or all registrations of a particular client. Note that a single multimedia conference can give rise to several calls with different Call-IDs, e.g., if a user invites a single individual several times to the same (long-running) conference. For an INVITE request, a callee user agent server SHOULD NOT alert the user if the user has responded previously to the Call-ID in the INVITE request. If the user is already a member of the conference and the conference parameters contained in the session description have not changed, a callee user agent server MAY silently accept the call, regardless of the Call-ID. An invitation for an existing Call-ID or session can change the parameters of the conference. A client application MAY decide to simply indicate to the user that the conference parameters have been changed and accept the invitation automatically or it MAY require user confirmation. A user may be invited to the same conference or call using several different Call-IDs. If desired, the client MAY use identifiers within the session description to detect this duplication. For example, SDP contains a session id and version number in the origin (o) field. The REGISTER and OPTIONS methods use the Call-ID value to unambiguously match requests and responses. All REGISTER requests issued by a single client SHOULD use the same Call-ID, at least within the same boot cycle. Since the Call-ID is generated by and for SIP, there is no reason to deal with the complexity of URL-encoding and case-ignoring string comparison. Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host local-id = 1*uric "host" SHOULD be either a fully qualified domain name or a globally routable IP address. If this is the case, the "local-id" SHOULD be an identifier consisting of URI characters that is unique within "host". Use of cryptographically random identifiers [27] is RECOMMENDED. If, however, host is not an FQDN or globally routable IP address (such as a net 10 address), the local-id MUST be globally unique, as opposed
to unique within host. These rules guarantee overall global
uniqueness of the Call-ID. The value for Call-ID MUST NOT be reused
for a different call. Call-IDs are case-sensitive.
Using cryptographically random identifiers provides some
protection against session hijacking. Call-ID, To and From
are needed to identify a call leg. The distinction between
call and call leg matters in calls with third-party
control.
For systems which have tight bandwidth constraints, many of the
mandatory SIP headers have a compact form, as discussed in Section 9.
These are alternate names for the headers which occupy less space in
the message. In the case of Call-ID, the compact form is i.
For example, both of the following are valid:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
or
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
6.13 Contact
The Contact general-header field can appear in INVITE, ACK, and
REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In
general, it provides a URL where the user can be reached for further
communications.
INVITE and ACK requests: INVITE and ACK requests MAY contain Contact
headers indicating from which location the request is
originating.
This allows the callee to send future requests, such as
BYE, directly to the caller instead of through a series of
proxies. The Via header is not sufficient since the
desired address may be that of a proxy.
INVITE 2xx responses: A user agent server sending a definitive,
positive response (2xx) MAY insert a Contact response header
field indicating the SIP address under which it is reachable
most directly for future SIP requests, such as ACK, within the
same Call-ID. The Contact header field contains the address of
the server itself or that of a proxy, e.g., if the host is
behind a firewall. The value of this Contact header is copied
into the Request-URI of subsequent requests for this call if the
response did not also contain a Record-Route header. If the
response also contains a Record-Route header field, the address
in the Contact header field is added as the last item in the
Route header field. See Section 6.29 for details.
The Contact value SHOULD NOT be cached across calls, as it
may not represent the most desirable location for a
particular destination address.
INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY
insert a Contact response header. It has the same semantics in a
1xx response as a 2xx INVITE response. Note that CANCEL requests
MUST NOT be sent to that address, but rather follow the same
path as the original request.
REGISTER requests: REGISTER requests MAY contain a Contact header
field indicating at which locations the user is reachable. The
REGISTER request defines a wildcard Contact field, "*", which
MUST only be used with Expires: 0 to remove all registrations
for a particular user. An optional "expires" parameter indicates
the desired expiration time of the registration. If a Contact
entry does not have an "expires" parameter, the Expires header
field is used as the default value. If neither of these
mechanisms is used, SIP URIs are assumed to expire after one
hour. Other URI schemes have no expiration times.
REGISTER 2xx responses: A REGISTER response MAY return all locations
at which the user is currently reachable. An optional "expires"
parameter indicates the expiration time of the registration. If
a Contact entry does not have an "expires" parameter, the value
of the Expires header field indicates the expiration time. If
neither mechanism is used, the expiration time specified in the
request, explicitly or by default, is used.
3xx and 485 responses: The Contact response-header field can be used
with a 3xx or 485 (Ambiguous) response codes to indicate one or
more alternate addresses to try. It can appear in responses to
BYE, INVITE and OPTIONS methods. The Contact header field
contains URIs giving the new locations or user names to try, or
may simply specify additional transport parameters. A 300
(Multiple Choices), 301 (Moved Permanently), 302 (Moved
Temporarily) or 485 (Ambiguous) response SHOULD contain a
Contact field containing URIs of new addresses to be tried. A
301 or 302 response may also give the same location and username
that was being tried but specify additional transport parameters
such as a different server or multicast address to try or a
change of SIP transport from UDP to TCP or vice versa. The
client copies the "user", "password", "host", "port" and "user-
param" elements of the Contact URI into the Request-URI of the
redirected request and directs the request to the address
specified by the "maddr" and "port" parameters, using the
transport protocol given in the "transport" parameter. If
"maddr" is a multicast address, the value of "ttl" is used as
the time-to-live value.
Note that the Contact header field MAY also refer to a different
entity than the one originally called. For example, a SIP call
connected to GSTN gateway may need to deliver a special information
announcement such as "The number you have dialed has been changed."
A Contact response header field can contain any suitable URI
indicating where the called party can be reached, not limited to SIP
URLs. For example, it could contain URL's for phones, fax, or irc (if
they were defined) or a mailto: (RFC 2368, [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
(page 50 continued on part 3)
