SIP protocol (Chinese)-2

In the dialog, other related information will be sent. A conversation is an end-to-end sip relationship between two users that lasts for a certain period of time. The dialog process requires that the information between the two user proxies is ordered and the request is transmitted through the correct route. In this specification, only the invite request can be used to establish a session. When a UAC sends a request in a dialog, it not only follows the general UAC rules described in section 8th, but also follows the request rules in the dialog. Section 12th describes the dialog and discusses the creation and maintenance of the dialog, as well as the creation of a request in the dialog.

The most important method in SIP is the invite method, which is used to create sessions in different participants. A session is composed of a group of participants and media streams used for communication between them. Section 13th describes the initialization process of these sessions and the creation of one or more dialogs. Section 14th describes how to use an invite request in a dialog to change the attributes of a session. Finally, section 15th describes how to terminate a session.

Section 8th, 10, 11, 12, 13, 14, and 15 describes the complete UA core (section 9th describes cancellation and is used in UA core and proxy core ). Section 16th describes proxy servers, which are used for message routing between two UA instances.

6. Protocol definition
The rankings described below have additional significance for SIP:
Address-of-record: record address. An address-of-record (AOR) is a sip or sips uri that points to a host with a location service. This host can map a URI to a user's real physical location. Usually, the locating server is established through the registration service. An AOR is often considered as a "public address" of a user"
Back-to-Back useragent: a back-to-back user proxy (b2bua) is a logical entity that receives and processes Requests just like a user Proxy Server (UAs. To determine how to respond to a request, b2bua works like UAC and sends a request. But unlike the proxy, it maintains the dialog state and participates in every request in the established dialog. Because it is a direct connection between UAC and UAS, there is no need to define it.

Call: call. A call is an informal term. It refers to a communication behavior between an endpoint and is usually used to establish a multimedia conversation.
Call leg: the alias of the dialog. It is not used in this specification.

Call stateful: If a proxy stores the state of a conversation (from the invite at the beginning to the bye at the end of the conversation), the proxy server will have a status request. A call stateful proxy server must be stateful, but not necessarily stateful.

Client: client. A client is an arbitrary network element that sends a SIP request and receives a SIP response. The client may or may not interact with people. Both the user proxy client (UAC) and the proxy server are clients.

Conference: a multimedia session containing multiple participants (see later ).

Core: core. The core defines a specific category of the SIP entity. For example, a stateful and stateless proxy server, a user proxy or a registered server (Registrar) is defined ). All cores except the stateless Proxy Server are transaction users.

Dialog: Dialog. A dialog is an end-to-end sip relationship between two UA instances that last for a period of time. A conversation is created by a SIP message, just like a 2XX response to an invite request. Call identifier, local tag (local tag), and remote tag (peer tag) are used to mark a conversation. A conversation is officially called call leg in RFC 2543.

Downstream: it is the message transmission direction in the transaction. It refers to the direction of the Request stream from UAC to UAS,

Final response: Terminate the response. The response of a SIP transaction in a response terminal is opposite to the temporary response in the middle of the transaction. All 2XX, 3xx, 4xx, 5xx, and 6xx responses end up the response.

Header: header. The header field is used to describe the information of the SIP message in the SIP message header. It consists of a pile of header fields.

Header field: the header field. The header field is in the SIP message header field. A header field can be composed of multiple header field rows. A header field consists of a header domain name and (zero or multiple) header domain values. Multiple head domain values are separated by commas. Some header fields can have only one value. For example, a result field can have only one value.

Header field value: the value of the header field. A header field value is a single value. A header field can have 0 or multiple header field values.

Home domain: host machine. A host that provides the SIP service. It generally refers to the host of the URI in the record address specified in the registration service.

Informational response: the system prompts a response. Same as a temporary response.
Initiator, calling party, Caller: Start a session (and conversation) with invite. A caller has been playing this role since it initiates an invite request to establish a conversation and ends the conversation.

Invitation: an invite request.

Invitee, invited user, called party, callee: callee. The party that receives the invite request and establishes the session. A callee is called from receiving an invite request to terminating the dialogue established by invite.

Location service: locate the service. The location service is used to determine the possible location of the called party for the SIP forwarding or proxy server. It contains a table bound with address-of-record. Only when called can there be 0 to multiple records. Bound records can be added and deleted through multiple channels. This specification defines the Register Method to update the bound table.

Loop: loop. When a request arrives at a proxy server, the proxy server forwards the request. When the request arrives at the same proxy server again, it is called a loop. When the second arrival, request-Uri contains the information about the previous arrival, and there is nothing to change the forwarding policy, in this way, the request will be forwarded back again. Loop requests are incorrect. Therefore, the handler needs to detect and prevent loop requests in the Protocol.

Loose routing: the routing is lost. The proxy server will lose the route in the following cases.
A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route Header field. these procedures separate the destination of the request (present in the request-Uri) from the set of proxies that need
To be visited along the way (present in the route header field). A proxy compliant to these mechanic ISMS is also known as a loose router.

Message: Message. The protocol data transmitted between SIP elements is a message. A sip message can be either a request or a response.

Method: method. The method is the main function of server request processing. The method is carried by the request message itself. The typical methods are invite and bye.

Outbound Proxy: External proxy server. A proxy server receives a customer's request, even if it is not determined by request_uri. Generally, an UA will manually configure an external proxy server, or you can automatically configure one through an automatic configuration protocol.

Parallel search: Parallel search. In parallel search, the proxy server initiates a request to a location where multiple users may exist and waits for a response. Different from serial search, parallel search does not initiate the next search after the response of the previous request is returned, but initiates the search request one by one.

Provisional response: temporary response. The server is used to mark the response that you are processing, but this response does not end a SIP transaction. The 1xx response is temporary, and other responses indicate the end of the transaction.

Proxy, proxy server: proxy, proxy server. An intermediate entity. It acts as a client and a server, and provides request forwarding services for other clients. A proxy server first provides the routing service, that is, to ensure that the request is sent more "closer" to the target user. The proxy server is useful for certain mandatory policies (for example, checking whether a user is allowed to create a call ). A proxy server translation, and if necessary, will rewrite the request message before forwarding.

Recursion: loop and recursion. When a client generates a new URI request to the Contract header domain in response to the request, the request is recursive in the 3xx response. A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the contact header field in the response.

Redirect server: Redirection server. A redirection Server is a UAS server that generates a 3xx response and instructs the client to connect to another Uri.

Registrar: Register. A Register Server is a server that receives a register request. He puts the request information in the locating server, which makes it easy for the locating server to find the location information.

Regular Transaction: a regular transaction. Any transaction that does not contain invite, ack, or cancel is a general transaction.

Request: request. A sip message sent from a client to the server for specific functions.

Response: response. A sip message sent from the server to the client. Used to indicate the processing status of requests sent from the client to the server.

Ringback: Return tone. The return tone is a signal. A signal is sent to the caller to indicate that the called party is in ringing ).

Route Set: Route Set. A route set is a sequential sip or sips uri. These Uris describe the list of proxies that must pass a request. A route set can be self-adaptive, because the packet header contains record-route (Record Route), or the dependency configuration can be obtained.

Server: Server. A server is a network element that receives and processes requests and sends a response to the requester. A typical server is proxies, user agent servers, redirection server, and registration server.

Sequential search: sequential search. In the sequential search, the proxy server tries the contact address sequentially. Before processing the next request, you must wait for an end response from the previous request. The final response of a 2XX or 6xx series always ends a sequential query.

Session: Session. According to the SDP Description: "A multimedia session is a collection composed of multimedia senders and receivers, and includes data streams between senders and receivers. A multimedia conference is a typical multimedia session ." (RFC 2327 [1]) (a session can be one or more RTP sessino in SDP ). In definition, a callee can be invited multiple times by different callers to the same session. In SDP, a session can be specified by a collection string by the SDP user name, session ID, network type, address type, and address element.

SIP transaction: a sip transaction receives an event on the client and server, including the first request sent from the client to the server and the last one (not 1xx) the server sends an end response to the client. If the request is an invite request and the final response is a non-2XX response, the transaction also includes an ACK to respond to the server. The ack response to the 2XX response to the invite request is an independent transaction.

Spiral: backtracking. A backtracing refers to a SIP request, which is routed to a proxy and forwarded, but is routed back to this proxy, but unlike loop (recursive, the header of the request packet returned from this route contains a part different from the original request packet, which makes the route forwarding determined by this proxy different from the previous one. Generally, this means that the request-Uri of a request is different from the previous request_uri. Backtracking is not an error, but a loop ). This is usually caused by call forwarding ). One user calls a joe@example.com. Example.com the proxy server forwards the request to Joe's PC and Joe's PC call is transferred to the bob@example.com. This request is forwarded back to the example.com proxy server. But this is not a loop ). Because the target address of the request is changed to another user, this is backtracking, which is a legal situation.

Stateful Proxy: a stateful proxy server. Logically, a stateful Proxy Server is a transaction state machine of the client and server defined in this specification that is maintained during the process of processing a request. It is also a transaction stateful proxy ). A specific stateful proxy is defined in section 16th. One (transaction) stateful proxy server and one call stateful proxy are not the same thing.

Stateless Proxy: stateless proxy server. Logically, the stateless proxy server does not maintain the transaction state machine between the client and the server during request processing. A stateless proxy server directly forwards each received request and each received response.

Strict routing: strict routing. If you review the rfc2543 protocol (and require prior work in progress versions of this RFC), the routing rules are a strict route. Under this rule, if the header contains the route domain, the proxy server deletes the request_uri domain content. This document does not require strict routing. This document only requires loose routing. The proxy server that supports strict routing is also called a strict router.

Target refresh request: Target refresh request. A target refresh request is a request sent in a dialog to change the target of the dialog.

Transaction user (TU): Transaction user. The protocol layer on the Transaction layer. Tu includes the UAC core, UAS core, and proxy core.

Upstream: upstream stream. The direction of the Message flow in the transaction. It refers to the Message flow direction from the user Proxy Server (UAs) to the user proxy client (UAC.

URL-encoded: a string of characters encoded according to the RFC2396-2.4 section.

User Agent client (UAC): the user agent client. The user agent client is a logical concept. It creates a new request and sends the request using the client transaction state machine. The UAC role only exists in transactions. In other words, UAC is a short piece of code that initializes a request and follows the UAC rules in the transaction. If it receives a request next, in that transaction, it is used as a UAS to process the request.

UAC core: UAC core. A set of functions implemented by UAC on the transaction and transport layers.

User Agent Server (UAs): the user proxy server. UAs is a logical entity that responds to SIP requests. Respond to, reject, or forward the corresponding request. The UAS role exists in the transaction. In other words, it is a small piece of software that responds to the request and exists as a UAS in the transaction. If he sends a request, he will exist as a UAC in the transaction.

UAS core: the UAS core. A set of functions implemented by UAS on the transaction and transport layers.

User Agent (UA ). The concept of a logical entity, including UAC and UAS.
UAC and UAS, like proxy servers and forwarding servers, are defined in the principle of transaction by (Serial transaction processing. For example, when an invite initialization request is sent, UA initializes a call action as UAC, and UA responds as UAS when the called party receives a bye request. Similarly, the same code can process one request as a proxy server and another request as a redirection server.

The proxy, location, and Registrar servers are all logical entities, which may be implemented as a single application.

7. SIP Message:
The SIP protocol is a text-based protocol that uses the UTF-8 character set (rfc2279 [7]).
A sip message can be either a request from the client to the server, or a response from the server to the client.
Even if the character set and syntax details are different, the request (7.1) and response (7.2) messages are both in rfc2822 format. (The SIP allowed packet header domain is not the standard rfc2822 packet header domain ). Both types of messages are composed of one starting line, one or more packet header fields, and one optional message Chinese.

General Message = start line
* Message Header
CRLF
[Message Body]
Start line = request line/status line

The start line and each header line, empty lines, must be composed of carriage return line breaks (CRLF ). Even if the message has no Chinese characters, there must be a blank line to follow.
Apart from the differences in character sets, the formats of many SIP messages and headers are the same as those of HTTP/1.1. Here we will not repeat its syntax and semantics. We use [HX. Y] to mark the x.y section of the HTTP/1.1 Standard (rfc2616 [8.
SIP is not an HTTP superset or extension.
7.1 requests
SIP requests are differentiated based on the request-line in the starting line. A request_line contains the method name, request-Uri, and Protocol version separated by a single space (SP.
Request-line ends with CRLF. Cr or lf is not allowed to appear elsewhere except as the row end mark. Liner whitespace LWS)

Request-line = method SP request-Uri SP sip-version CRLF
Method: This specification sets forth 6 methods: register is used to register contact information, invite, ack, and cancel are used to establish a session, bye is used to end the session, and options is used to query server load. SIP Extension and standard RFC append may include extension methods.
Request-Uri: Request-Uri is a sip or sips uri, which is described in Section 19.1. It can also be a common uri (RFC 2396 [5]). It indicates the user or service address used by the request. Request-Uri cannot contain white space or control characters, and it cannot be enclosed by "<>.
The SIP element supports the request-Uris defined in addition to the SIP or sips. For example, "tel" URI mode (RFC 2806 [9]). SIP elements can use their own mechanisms to convert non-Sip URIs to sip Uris, SIPs Uris, or other Uris.
Sip-version: the request and response messages both contain the currently used sip version, which follows [h3.1] (similar to replacing HTTP with SIP and using SIP/2.0 with HTTP/1.1) version, version dependency, upgrade version number. For an application, the sent SIP message must contain the SIP-version "Sip/2.0 ". This sip version string is case-insensitive, but must be capitalized in implementation.
Unlike HTTP/1.1, SIP processes the version number as a text string. There should be no difference in implementation.
7.2 response
The difference between a SIP response and a SIP request is whether the start-line contains a status-line. A status-line is a Protocol version string before the status-code expressed by a number. Each element is separated by a single Sp (Space.
Except for the last ending sign, CR/LF is not allowed to appear elsewhere.
Status-line = sip-version SP status-code SP reasong-phrase CRLF
Status-code is a three-digit result code used to mark a request result. Reason-phrase is a brief description of status-code. Status-code is used for automatic processing, but reason-phrase is used to show users. A client does not need to display or interpret this reason-phrase. In this document, we recommend that you output this reason-phrase. You can select other texts in the implementation, for example, display them in the appropriate language specified in the request header.
The first number of status-code indicates the type of response. The next two numbers are not used for classification. For this reason, any status code between 100 and 199 can be collectively referred to as "1xx response". Similarly, in 200 to 299, it can be collectively referred to as "2XX response", and so on. Sip/2.0 allows 6 types of responses:
1xx: temporary response-the request has been received and is being processed.
2XX: Successful processing-the request has been successfully received and processed correctly.
3xx: Redirection-additional operations are required to complete this request. This request is forwarded to other servers for processing.
4xx: client error-The request contains an incorrect format or cannot be completed on this server.
5xx: Server Error-the server cannot properly process this apparently legal request.
6XX: Global error-the request cannot be processed by any server.
Section 21 defines detailed code descriptions.
7.3 header Domains
The syntax and semantics of the SIP header and HTTP header are similar. In particular, the SIP header domain complies with [h4.2] the definition of the message header syntax and the rules of the multi-row extended header domain. (The latter is specified in HTTP with implicit whitespace and folding ). This specification complies with rfc2234 [10] and uses clear spaces and encapsulation as the internal syntax rules.
[H4.2] also defines multiple header domains with the same domain name. Their values are separated by commas (,) and can be merged into a header domain. This also applies to sip, but the details are slightly different, because the syntax is different. In fact, the header Syntax of any SIP is based on the following paradigm:
Header = "header-name" hcolon header-value * (comma header-value)
This can be merged into multiple header domains with the same domain name, to a single header domain separated by commas. The contact header field can be separated by commas (,) Except when the field value is.
7.3.1 header domain format.

The header fields follow the common header domain format defined in section 2.2 of rfc2822. Each header domain is composed of a domain name with a colon (":") and a domain value.
Field-Name: field-Value
The regular Syntax of message headers is described in section 25.
In the message header, any number of white spaces can be left or right of the colon. However, we recommend that you avoid spaces between the domain name and the colon, we recommend that you use a single space (SP) between the colon and value ).
Subject: Lunch
Subject: Lunch
Subject: Lunch
Subject: Lunch
Therefore, the above are both valid and equal, but the last one is what we recommend.
The header field can be extended into multiple rows, as long as at least one SP or horizontal tab (HT) is used before each additional row. This multi-row header field is considered as a single SP character at the end of a row and the blank Sp (or HT) before the next line. Therefore, the following examples 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 different domain names in the header domain is meaningless. However, we strongly recommend that you use routing-related domains (such as via, route, record-route, proxy-require, Max-forwards, and proxy-authorization) put it at the front of the message header to increase the processing speed. The order between domains with the same domain name is very important. Only when the Domain value of a single header field is a list that can be separated by commas (,) can it be expressed as multiple header fields of the same domain name (that is, if the syntax defined by 7.3 is followed ). That is to say, the multi-head domain of the same domain name must be changed to a "Domain Name" without changing the message semantics:
Domain value "; this conversion is to add the domain values of each domain in sequence, and the domain values are separated by commas. There are several exceptions to this rule: www-authenticate, authorization, proxy-authenticate, and proxy-Authorization header fields. Multiple header domain lines can appear in the message header, but because their syntax does not follow the general format defined in 7.3, they cannot be merged into a single header domain line.
In terms of implementation, you must be able to process both the case of multi-head domain rows and the case of single header domain rows merged by commas.
The following headers are equal:
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 are valid but not equal.
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 each header Domain value depends on its header domain name. It can be a TEXT-UTF8 character in any order, or a combination of spaces, tags, delimiters, and enclosed strings. A common domain value format is included in many fields. The format of this field value is a combination of parameter names and parameter values separated by semicolons:
Field-Name: field-value * (; parameter-name = parameter-value)
Although there can be any number of parameter-name/parameter-value pairs in the Domain value, the same parameter-name cannot exist (uniqueness ). Except for the header domain, the domain name, Domain value, and parameter name parameter-value in the header domain are case insensitive. The markup word is always case insensitive. Unless otherwise specified, the string of the quotation mark string is case sensitive. For example:
Contact: <SIP: alice@atlanta.com>; expires = 3600
And
Contact: <SIP: alice@atlanta.com>; expires = 3600
Same.
Content-Disposition: Session; handling = optional
And
Content-Disposition: Session; handling = optional
Same.
The following two header fields are different:
Warning: 370 devnull "choose a bigger pipe"
Warning: 370 devnull "choose a bigger pipe"