SIP protocol parsing and implementation (C and C use Osip) 3

Chapter 3 SIP messages

SIP is a text-based protocol that uses the UTF-8 character set (rfc2279 ). A sip message can be a request sent from a client to a server, or a response sent from a server to a client.

Both requests (rfc3261 section 7.1) and responses (rfc3261 section 7.2) are in the format described in rfc2822. However, there are some differences between character sets and some syntax details. All types of messages are composed of one start-line, one or more header fields, and one empty line that identifies the end Of the header field, and an optional message body.
Generic-message = start-line
* Message-Header
CRLF
[Message-body]
Start-line = request-line/status-line

The start line, header field, and header field must be terminated by the line feed carriage return (CRLF. Note that even if there is no message body, there must be a blank line with the header domain ID ending.

Except for the preceding character sets, the syntax of most SIP messages and header fields is the same as that of HTTP/1.1. However, SIP is not an extension of HTTP.

Section 1 request

The starting line of the SIP request is a request line ). A request line contains a method, a request URI, and a Protocol version ). They are separated by spaces (SP.

The request line ends with CRLF. In the request line, except the last CRLF, Cr or lf is not allowed. Linear Spaces (representing one or more consecutive spaces LWS) are not allowed in each element ).
Request-line = method SP request-Uri SP sip-version CRLF

Method: six methods are defined here. register is used to register contact information. Invite, ack, and cancel are used to build a meeting. Bye is used to terminate the meeting. Options is used to query server capabilities. The SIP Extension protocol may define other methods.

Request-Uri: The request URI is a sip URI or sips uri described in rfc3261 19.1 or rfc2396. It indicates a request sent to a user or service address. The request Rui must not contain spaces or control characters. It must not be nested in "<>.
The SIP element may support a URI in a mode other than "sip" or "sips. For example, the URI mode "tel" described in rfc2806 ". The SIP element supports processing non-"sip" and "sips" URIs.

Sip-version: the request and response messages both contain the currently used sip version. The current version information must be "Sip/2.0 ".

Section 2 response

The starting line of the SIP response is a status line ). A status line consists of a Protocol version followed by a number indicating the status code and a reason-phrase. They are separated by spaces. Except for the final CRLF, Cr or lf is not allowed.
Status-line = sip-version SP status-code SP reason-phrase CRLF

The status code is a three-digit integer that indicates the response to the request. A phrase is a brief description of the status code. The status code is automatically set, and the phrase is set by the user. A user does not need to see a phrase.

The highest digit of the status code defines the type of the response. The last two digits are meaningless. Any status code ranging from 100 ~ The response between 199 is called "1xx response", and any status code is 200 ~ Responses between 299 are called "2XX responses", and so on. The maximum number of BITs allowed for SIP/2.0 is 6 digits:
1xx: Temporary --- the request has been received and continues to be sent backward.
2XX: Successful --- the request has been successfully received, understood, and accepted.
3xx: Redirection-further processing is required to complete the request.
4xx: client error-The request contains incorrect syntax or cannot be completed on this server.
5xx: Server Error --- a request that is obviously invalid and the server handles the error.
6XX: Global error-the request cannot be completed on any server.
 
Rfc3261 section 21st defines these categories and describes each status code.

Section 3 header fields

The syntax and semantics of the SIP header domain are similar to those of the HTTP header domain. The syntax format is as follows:
Header = "header-name" hcolon header-value * (comma header-value ),
If there are multiple headers with the same name, they can be merged into a header domain. The value of the header domain is separated by commas.
The header field complies with the general header field format described in section 2.2 of rfc2822. Each header field consists of a colon followed by the header domain name and the value of the header field. The syntax of the message header is described in rfc3261 section 25th. There can be any number of spaces on either side of the colon. Generally, do not use spaces between the header domain name and the colon, but use a space between the colon and the header Domain value.
Subject: Lunch
Subject: Lunch
Subject: Lunch
Subject: Lunch
The above header fields are valid and they are equivalent. However, the last header domain format is recommended.

A header field can be expanded to multiple rows. Each expanded row must start with at least one space or tab (HT. These spaces or tabs are considered as one space. Therefore, the following header fields 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 sequence of headers with different domain names is not important. However, it is recommended that the header domain (such as via, route, record-route, proxy-require, Max-forwards, and proxy-authorization) to be processed by the proxy server be placed on the top of the message, to accelerate resolution efficiency. The sequence of headers with the same header domain name is important. In a message, multiple headers with the same domain name can appear. In this case, it is equivalent to a header line and multiple header field values separated by commas. If multiple header domain rows with the same header Domain value are used, it must be easily merged into a single row's header domain, and the message semantics will not be changed. When merging, the value of each header field row is added at the beginning of the header field value of a single row and separated by commas. Except for WWW-authenticate, authorization, proxy-authenticate, and proxy-Authorization header fields. If multiple headers with the same header domain name appear, they cannot be merged. Each of the following header fields is 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>

The following groups of header fields are valid but they are not equivalent:
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 value of the header field can contain numbers, spaces, symbols, delimiters, or reference strings (strings with double quotation marks) for the UTF-8 ). Some header fields are appended with a series of parameter names and parameter value pairs separated:
Field-Name: field-value * (; parameter-name = parameter-value)
Although the number of parameters is unlimited, each parameter name can only appear once.

Header fields are case-insensitive. Unless otherwise specified, the header domain name, header Domain value, parameter name, and parameter value are case insensitive. The symbol is often in lower case. Unless otherwise specified, the referenced string is case sensitive. For example:
Contact: <SIP: alice@atlanta.com>; expires = 3600
Equivalent
Contact: <SIP: alice@atlanta.com>; expires = 3600

Content-Disposition: Session; handling = optional
Equivalent
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"

Section 4 header domain classification

Some header fields only make sense to the request or only to the response. They are called request header fields or response header fields respectively. If a header domain that appears in a message does not conform to its category (for example, a request header domain appears in the Response Message), it must be ignored. Rfc3261 section 20th defines the classification of each header field.

Section 5 concise format

SIP supports abbreviations for general header domain names. This is useful when big data cannot be transmitted (for example, when UDP is used, the maximum transmission unit MTU is exceeded ). These abbreviations are defined in rfc3261 section 20th. The header domain name and the long header domain name can appear in a message at the same time, and the semantics remains unchanged.