AASTRA BluStar 8000i BAS-Mode Administrator Guides EN - Manual (Page 167)

Abstract (from RFC3261):
41-001391-00 Rev 03 – 04.2012 13-4
The SIP Request-Response Transaction Mechanism
The following description of the request-response transaction mechanism is composed of selected excerpts from the
standard.
SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279).
A SIP message is either a request from a client to a server, or a response from a server to a client.
Both Request and Response messages use the basic format of RFC 2822, even though the syntax differs in character set
and syntax specifics. (SIP allows header fields that would not be valid RFC 2822 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
start-line = Request- / Status-Line [ message-body ]
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.
However, SIP is not an extension of HTTP.
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, docu-
mented in standards track RFCs, may define additional methods.
Request-URI:
The Request-URI is a SIP or SIPS URI or a general URI. 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. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in either 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.
Responses
SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the pro-
tocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a sin-
gle SP character.