SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279(-> 3629std63)
[7]).
A SIP message is either a request from a client to a server, or a
response from a server to a client.
Both Request (section 7.1) and Response (section 7.2) messages use
the basic format of RFC 2822prop [3], even though the syntax differs in
character set and syntax specifics. (SIP allows header fields that
would not be valid RFC 2822prop header fields, for example.) Both types
of messages consist of a start-line, one or more header fields, an
empty line indicating the end of the header fields, and an optional
message-body.
generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line
The start-line, each message-header line, and the empty line MUST be
terminated by a carriage-return line-feed sequence (CRLF). Note that
the empty line MUST be present even if the message-body is not.
Except for the above difference in character sets, much of SIP's
message and header field syntax is 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 2616draft [8]).
However, SIP is not an extension of HTTP.
7.1. Requests
SIP requests are distinguished by having a Request-Line for a start-
line. A Request-Line contains a method name, a Request-URI, and the
protocol version separated by a single space (SP) character.
The Request-Line ends with CRLF. No CR or LF are allowed except in
the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed
in any of the elements.
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Method: This specification defines six methods: REGISTER for
registering contact information, INVITE, ACK, and CANCEL for
setting up sessions, BYE for terminating sessions, and
OPTIONS for querying servers about their capabilities. SIP
extensions, documented in standards track RFCs, may define
additional methods.
Request-URI: The Request-URI is a SIP or SIPS URI as described in
Section 19.1 or a general URI (RFC 2396(-> 3986std66) [5]). It indicates
the user or service to which this request is being addressed.
The Request-URI MUST NOT contain unescaped spaces or control
characters and MUST NOT be enclosed in "<>".
SIP elements MAY support Request-URIs with schemes other than
"sip" and "sips", for example the "tel" URI scheme of RFC
2806(-> 3966prop) [9]. SIP elements MAY translate non-SIP URIs using any
mechanism at their disposal, resulting in SIP URI, SIPS URI,
or some other scheme.
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". The SIP-Version string is case-insensitive,
but implementations MUST send upper-case.
Unlike HTTP/1.1, SIP treats the version number as a literal
string. In practice, this should make no difference.
7.2. Responses
SIP responses are distinguished from requests by having a Status-Line
as their start-line. A Status-Line consists of the protocol version
followed by a numeric Status-Code and its associated textual phrase,
with each element separated by a single SP character.
No CR or LF is allowed except in the final CRLF sequence.
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
The Status-Code is a 3-digit integer result code that indicates the
outcome of an attempt to understand and satisfy a 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. A client
is not required to examine or display the Reason-Phrase.
While this specification suggests specific wording for the reason
phrase, implementations MAY choose other text, for example, in the
language indicated in the Accept-Language header field of the
request.
The first digit of the Status-Code defines the class of response.
The last two digits do not have any categorization role. For this
reason, any response with a status code between 100 and 199 is
referred to as a "1xx response", any response with a status code
between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows
six values for the first digit:
1xx: Provisional -- 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.
Section 21 defines these classes and describes the individual codes.
SIP header fields are similar to HTTP header fields in both syntax
and semantics. In particular, SIP header fields follow the [H4.2]
definitions of syntax for the message-header and the rules for
extending header fields over multiple lines. However, the latter is
specified in HTTP with implicit whitespace and folding. This
specification conforms to RFC 2234(-> 4234draft) [10] and uses only explicit
whitespace and folding as an integral part of the grammar.
[H4.2] also specifies that multiple header fields of the same field
name whose value is a comma-separated list can be combined into one
header field. That applies to SIP as well, but the specific rule is
different because of the different grammars. Specifically, any SIP
header whose grammar is of the form
header = "header-name" HCOLON header-value *(COMMA header-value)
allows for combining header fields of the same name into a comma-
separated list. The Contact header field allows a comma-separated
list unless the header field value is "*".
Header fields follow the same generic header format as that given in
Section 2.2 of RFC 2822prop [3]. Each header field consists of a field
name followed by a colon (":") and the field value.
field-name: field-value
The formal grammar for a message-header specified in Section 25
allows for an arbitrary amount of whitespace on either side of the
colon; however, implementations should avoid spaces between the field
name and the colon and use a single space (SP) between the colon and
the field-value.
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
Thus, the above are all valid and equivalent, but the last is the
preferred form.
Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or horizontal tab (HT). The line
break and the whitespace at the beginning of the next line are
treated as a single SP character. Thus, the following are
equivalent:
Subject: I know you're there, pick up the phone and talk to me!
Subject: I know you're there,
pick up the phone
and talk to me!
The relative order of header fields with different field names is not
significant. However, it is RECOMMENDED that header fields which are
needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
Max-Forwards, and Proxy-Authorization, for example) appear towards
the top of the message to facilitate rapid parsing. The relative
order of header field rows with the same field name is important.
Multiple header field rows 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 (that is, if follows the grammar
defined in Section 7.3). It MUST be possible to combine the multiple
header field rows 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 exceptions
to this rule are the WWW-Authenticate, Authorization, Proxy-
Authenticate, and Proxy-Authorization header fields. Multiple header
field rows with these names MAY be present in a message, but since
their grammar does not follow the general form listed in Section 7.3,
they MUST NOT be combined into a single header field row.
Implementations MUST be able to process multiple header field rows
with the same name in any combination of the single-value-per-line or
comma-separated value forms.
The following groups of header field rows are valid and equivalent:
Route: <sip:alice@atlanta.com>
Subject: Lunch
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Subject: Lunch
Subject: Lunch
Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
<sip:carol@chicago.com>
Each of the following blocks is valid but not equivalent to the
others:
Route: <sip:alice@atlanta.com>
Route: <sip:bob@biloxi.com>
Route: <sip:carol@chicago.com>
Route: <sip:bob@biloxi.com>
Route: <sip:alice@atlanta.com>
Route: <sip:carol@chicago.com>
Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
<sip:bob@biloxi.com>
The format of a header field-value is defined per header-name. It
will always be either an opaque sequence of TEXT-UTF8 octets, or a
combination of whitespace, tokens, separators, and quoted strings.
Many existing header fields will adhere to the general form of a
value followed by a semi-colon separated sequence of parameter-name,
parameter-value pairs:
field-name: field-value *(;parameter-name=parameter-value)
Even though an arbitrary number of parameter pairs may be attached to
a header field value, any given parameter-name MUST NOT appear more
than once.
When comparing header fields, field names are always case-
insensitive. Unless otherwise stated in the definition of a
particular header field, field values, parameter names, and parameter
values are case-insensitive. Tokens are always case-insensitive.
Unless specified otherwise, values expressed as quoted strings are
case-sensitive. For example,
Contact: <sip:alice@atlanta.com>;expires=3600
is equivalent to
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
and
Content-Disposition: session;handling=optional
is equivalent to
content-disposition: Session;HANDLING=OPTIONAL
The following two header fields are not equivalent:
Warning: 370 devnull "Choose a bigger pipe"
Warning: 370 devnull "CHOOSE A BIGGER PIPE"
Some header fields only make sense in requests or responses. These
are called request header fields and response header fields,
respectively. If a header field appears in a message not matching
its category (such as a request header field in a response), it MUST
be ignored. Section 20 defines the classification of each header
field.
7.3.3. Compact Form
SIP provides a mechanism to represent common header field names in an
abbreviated form. This may be useful when messages would otherwise
become too large to be carried on the transport available to it
(exceeding the maximum transmission unit (MTU) when using UDP, for
example). These compact forms are defined in Section 20. A compact
form MAY be substituted for the longer form of a header field name at
any time without changing the semantics of the message. A header
field name MAY appear in both long and short forms within the same
message. Implementations MUST accept both the long and short forms
of each header name.
7.4. Bodies
Requests, including new requests defined in extensions to this
specification, MAY contain message bodies unless otherwise noted.
The interpretation of the body depends on the request method.
For response messages, the request method and the response status
code determine the type and interpretation of any message body. All
responses MAY include a body.
The Internet media type of the message body MUST be given by the
Content-Type header field. If the body has undergone any encoding
such as compression, then this MUST be indicated by the Content-
Encoding header field; otherwise, Content-Encoding MUST be omitted.
If applicable, the character set of the message body is indicated as
part of the Content-Type header-field value.
The "multipart" MIME type defined in RFC 2046draft [11] MAY be used within
the body of the message. Implementations that send requests
containing multipart message bodies MUST send a session description
as a non-multipart message body if the remote implementation requests
this through an Accept header field that does not contain multipart.
SIP messages MAY contain binary bodies or body parts. When no
explicit charset parameter is provided by the sender, media subtypes
of the "text" type are defined to have a default charset value of
"UTF-8".
The body length in bytes is provided by the Content-Length header
field. Section 20.14 describes the necessary contents of this header
field in detail.
The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
(Note: The chunked encoding modifies the body of a message in order
to transfer it as a series of chunks, each with its own size
indicator.)
Unlike HTTP, SIP implementations can use UDP or other unreliable
datagram protocols. Each such datagram carries one request or
response. See Section 18 on constraints on usage of unreliable
transports.
Implementations processing SIP messages over stream-oriented
transports MUST ignore any CRLF appearing before the start-line
[H4.1].
The Content-Length header field value is used to locate the end of
each SIP message in a stream. It will always be present when SIP
messages are sent over stream-oriented transports.
