Session Initiation Protocol

Session Initiation Protocol (SIP) is a control (signaling) Protocol for the application layer of Network calls and conferences. It is mainly a multimedia communication protocol based on an IP network. All the signaling functions it can implement also use RTP as the media transmission protocol. It was initially proposed by the IETF mmusic (multiparty multimedia session control) Working Group.

The main functions of SIP are: 1. Network Office; 2. Instant Messaging; 3. Instant status management; 4. Network IP phone number; 5. Network conference. It consists of the following parts,
Underlying layer: UA toolkit API (Toolkit)
Interface Layer: Call Control (API), user status management (API), instant messaging (API)
Application Layer:
UAC (client) Process
Call Control-> initialization (including registration)-> session call establishment-> media and data channel negotiation-> SDP packet Parsing
User status-> subscription and notification-> setting of status information-> query of status information
Instant Messaging: receiving instant messages
UAS (server side)
Meeting Management: establishes a meeting, joins a meeting, modifies the meeting, leaves the meeting, ends the meeting, queries the relevant information of the Meeting, and publishes the meeting Status;
User Management: Query location information, user authentication, adding users, and deleting users;
Media Management: Initialize (negotiate media channels, specify ports and attributes), send media streams, receive media streams, and add or delete media streams.
The RTP/RTCP protocol stack is provided to send, receive, and transmit media streams.

The connection address is URL-based and easy to use. The format is user name @ host address, callednumber @ PSTN gateway address, and Tel: 010-62281234. The most powerful feature of SIP is the user positioning function. Messages and messages are all encoded in text. SIP is used to initiate a session, manage multimedia sessions attended by multiple participants, and dynamically adjust session attributes. SIP is independent of Low-layer protocols. Generally, UDP and other connectionless protocols are used, and their application-layer reliability mechanisms are used to ensure reliable message transmission.

Important concepts:
UA: the user agent describes a common user terminal and user agent. There are clients and servers in the SIP. A client is an application that establishes a connection with the server to send requests to the server. The user agent and proxy contain clients. A server is an application that provides services and sends responses to requests sent from clients. There are four types of basic servers:
· User proxy server: contacts the user when receiving a SIP request and returns a response on behalf of the user.
· Proxy server: initiates requests on behalf of other clients, acting as both a server and a media program of the client. It may rewrite the content in the original request message before forwarding the request.
· Redirection server: receives a SIP request, maps the original address in the request to zero or multiple new addresses, and returns them to the client.
· Registration server: receives client registration requests to complete user address registration.

It is relatively simple to analyze the lexical and syntax of messages in text format. It has the distributed multicast function.
Features provided: 1) Name Translation and user positioning: 2) feature negotiation: 3) Call participant Management 4) Call Feature Change
There are two elements in SIP: SIP User proxy and SIP network server.
The user agent is the terminal system element of the call, and the SIP server is the network device that processes the connection orders related to multiple calls. The user agent itself has a client element (User proxy client UAC) and a server element (User Proxy Server UAS ). The client element initiates a call and the server element responds to the call. This allows point-to-point calls to be completed through the client-server protocol.
The main function of the SIP server is to provide name resolution and user location. You can obtain an email address or a phone number associated with the called party. With this information, the caller's user agent can determine the specific server to parse the address information-this may involve many servers on the network. The SIP proxy server receives requests, determines where these requests are sent, and sends them to the next server (using the next hop routing principle ). There can be multiple hops in the network.

Structure of the SIP protocol stack:
The bottom layer of SIP is syntax and encoding.
The second layer is the transport layer: it defines how a client on the network sends requests and receives responses, and how a server receives and sends responses.
The third layer is the Transaction layer: the Transaction layer processes Application Layer retransmission, matches the response to the request, and the application layer timeout.
Tasks completed by any user's proxy client (UAC) are generated using a set of transactions. SIP uses an email address to indicate the user address. Each user is identified by a hierarchical URL, which is constructed by elements such as the user's phone number or host name (for example, SIP: user@company.com ). Because of its similarity with the email address, SIP URLs is easy to associate with the user's email address. A caller uses invite to initiate a call. When a user wants to call another user, the caller uses invite to initiate a call. The request contains sufficient information for the caller to participate in the session. If the client knows where the other party is, it can directly send the request to the IP address of the other party. If you do not know, the client sends the request to the locally configured SIP network server. If the server is a proxy server, it will parse the location of the called USER and send the request to them. There are many ways to complete the previous step, such as searching DNS or accessing the database. The server can also be a redirection server, which can return the location of the called user to the called client for direct contact with the user. In the process of locating the user, the SIP network server can, of course, proxy or redirect the call to another server until it reaches a server that explicitly knows the IP address of the called user. Once a user address is found, the request is sent to the user. Several options are available. In the simplest case, the user's phone client receives the request-that is, the user's phone rings. If the user accepts the call, the customer uses the specified capability of the client software to respond to the request and establish a connection. If the user rejects the call, the session will be redirected to the voice mail server or another user. For "specify capabilities", refer to the features you want to enable. For example, the client software can support video conferencing, but the user only wants to use audio conferencing, then only the audio function is enabled.
Sip also has two important features. The first is that the stateful sip proxy server can split incoming calls or replicate incoming calls, so that several extension branches can run simultaneously. The branch of the first response receives the call. This feature is convenient when a user is working between two locations (such as a lab and an office) or at the same time the manager and his/her secretary are ringed. The second feature is the unique ability of SIP to return different media types. For example, you can contact a company. When the SIP server receives a connection request from the client, it can return to the client through the web interactive voice response page, this page has available department branches or users on the list. After clicking the appropriate link, a request is sent to the selected user to create a call.

There are two types of SIP messages:
● Request: Send from client to server
● Response: from the server to the client
The SIP request message contains three elements: request line, header, and message body. A sip response message contains three elements: Status line, header, and message body. The request line and header field define the nature of a call based on the business, address, and Protocol features. The message body is independent of the SIP protocol and can contain any content.

SIP defines the following methods:
Invite -- invite users to join the call.
Bye -- terminate the call between two users on a call.
Options -- request information about server capabilities.
Ack -- confirm that the client has received the final response to invite.
Register -- provides address resolution ing to let the server know the location of other users.
Info -- used to send messages in a session.

2.1 Overall description of the SIP Message
There are two types of SIP messages: client-to-server request and server-to-client response ). A sip Message consists of a start-line (START-line), one or more fields (fields), and one empty line (CRLF) that indicates the end of the message header) and as an optional message body. The header describing the message body is called the entity header ). Generic-message = start-line * message-header CRLF [Message-body] start line is divided into two types: Request Line and status line, the request line is the starting line of the request message, and the Status line is the starting line of the Response Message. Message Headers include general-header, request-header, response-header, and entity-header.

2.2 The format of the SIP request message is as follows.
Request = request-line * (General-header | request-header | entity-header CRLF [Message-body] request line (request-line) is marked with a method, request-Uri and Protocol version (SIP-version) are followed by the Enter key, and each element is separated by a space key. Request-line = method SP request-Uri SP sip-version CRLF sip uses the term "method" to describe the description section. The method identifier is case sensitive. SIP defines the following methods (methods ). Method = "invite" | "Ack" | "options" | "bye" | "cancel" | "register" | "info"-invite method is used to invite users and services to one session. In the message body of the invite request, you can describe the sessions that the called party is invited to participate in. For example, the caller can receive the media type, the media type sent, and some parameters: the successful response to the invite request must indicate in the Response Message Body that the caller is willing to receive the media, or describe the media sent by the callee. The server can automatically respond to the Meeting invitation with the 200 (OK. The-ack request is used by the client to verify to the server that it has received the final response to the invite request. Ack is only used with the invite request. The confirmation of the 2XX final response is sent by the client user proxy, and the confirmation of other final responses is sent by the first proxy that receives the response or the first client user proxy. The values of the to, from, call-ID, and CSeq fields in the ACK request are copied from the values of the corresponding fields in the inivite request. -Options is used to query the server's capabilities. If the server thinks it can contact the user, a capability set can be used to respond to the options request. The proxy and redirect server only need to forward the request without showing its capabilities. The from and to of options contain the addresses of the master and called respectively, and the from and to (TAG parameters may be added) in the response to the options request) the value of the call-Id field is copied from the field value returned by the options request to get bye. the user agent client uses bye requests to indicate to the server that it wants to release the call. A bye request can be forwarded as an invite request, either by the caller or by the callee. The caller must send a bye request before releasing (hanging up) the call. The caller must stop sending a media stream to the caller who sends a bye request. -The cancel request is used to cancel an ongoing request with the same call-ID, to, from, and CSeq (serial number only) fields, however, the request that has been completed cannot be canceled (if the server returns a final response, the request is deemed to have been completed ). In a cancel request, the call-ID, to, CSeq numeric and from fields are the same as those in the original request, so that the cancel request matches the request to be canceled. -The register method is used for the client to register the address information listed in the to field with the SIP server. The meaning of each field in the register request message header is defined as follows: To: contains the registered address record to be created or updated. From: contains the address record of the person who proposed the registration. Request-Uri: the destination address of the registration request. The value of the domain part of the address is the domain of the competent registrar, and the host part must be empty. Generally, the value of the address field in request-Uri is the same as that of the address field in. Call-ID: used to identify the request of a specific client. Registration requests from the same client should have the same call-Id field value at least within the same restart period. Users can register different addresses with different call-ID values, the subsequent registration request replaces the previous one. CSeq: The CSeq field values of registration requests with the same call-Id field values must be incremental, but the order is irrelevant. The server does not reject unordered requests. Contact: this field is optional. It is used to forward non-registration requests sent to the URI in the to field to the location given by the contact field. If the request does not contain the contact field, the registration remains unchanged. Expires: indicates the registration deadline. -The info method is an extension of the SIP protocol. It is used to transmit session-related control information, such as ISUP and ISDN Signaling messages, the use of this method remains to be standardized. For details, see ietf rfc 2976.

2.3 The format of the SIP response information is as follows.
Response = status-line * (General-header | response-header | entity-header CRLF [Message-body] Status line (status-line) starting with the Protocol version, next, the status code and related text descriptions, which are represented by numbers, end with the Enter key, and each element is separated by a space character (SP, except for the last CRLF sequence, carriage return or line feed characters are not allowed for this line. Status-line = sip-version SP status-code SP reason-phrase CRLF the three-digit status code and Reason code in the SIP protocol) the status code is used for machine identification operations. The reason phrase (reason-phrase) is a simple text description of the status code for manual identification operations. Status-code = 1xx (information) | 2XX (SUCCESS) | 3xx (redirection) | 4xx (client-error) | 5xx (Service-error) | 6xx (Global-failure) | the first digit of the extension-code status code defines the type of the response. In Sip/2.0, the first digit has 6 values, which are defined as follows: 1xx: informational-the request has been received and continues processing. 2XX: Success-action has been successfully received, understood, and introduced. 3xx: Redirection-further actions must be taken to complete the call request. 4xx: client error-the request has a syntax error or cannot be executed by the server. The client needs to modify the request and resend the request. 5xx: Server Error-server error. A valid request cannot be executed. 6XX: Global failure-No server can execute the request. Among them, the 1xx response is a temporary response (provisional response), and the other response is a final response ).

2.4 SIP message header field
The message definition of the SIP protocol is similar to that of HTTP in terms of syntax rules and definitions. Each header field follows the following format: field name, case-insensitive, followed by a colon, followed by a field value, there are multiple leading spaces (LWS) between the field value and the colon ). Message-header = field-name ":" [field-value] CRLF field-name = token field-value = * (field-content | LWS) (1) the general-header field is applicable to request messages and response messages. It contains the following fields: general-header = accept | accept-encoding | accept-language | call-ID | contact | CSeq | data | encryption | expires | from | organization | record-route | timestamp | to | user-Agent |, the Accept, accept-encoding, and accept-language fields are used by the client during request cancellation. It provides the acceptable response media type, encoding method, and Description Language: used by the server to indicate the media type and encoding method of the understandable request message in the 415 response, and Description Language. The call-Id field uniquely identifies a specific invitation or a client's registration request. A Multimedia conference can generate multiple calls with different call-IDs. The contact field provides a URL for further communication with this URL. The CSeq field identifies different requests sent by the server. If the call-id value is the same, the CSeq values must be different. The date field indicates the time when the first request or response message is sent. The resend message has the same data field value as the original message. The encryption field indicates that the content is encrypted, Which is end-to-end encryption. The expire field specifies the date and time when the message content expires. All messages must have the from field, which is the request initiator. The organization field specifies the name of the organization to which the entity that sends the request or response message belongs. The record-route field provides a globally reachable request-URI to identify the proxy server. The time-stamp field specifies the time when the client sends a request to the server. All messages must have the to field, which is used to indicate the recipient of the request. The User-Agent field contains information about the user agent client that initiates the request. The via field specifies the path to which the request message has passed so far. (2) The entity-header object header field is used to define information related to the message body. Entity-header = content-encoding | Content-Length | Content-Type content-encoding field indicates the content encoding method added to the message body. The Content-Length field indicates the size of the message body. The Content-Type field indicates the media type of the message body. (3) The request-header field is used for the client to upload additional information to the server, including information about the request and the client itself. Request-header = Authorization | contact; | hide; | max-forwards; | priority; | proxy-authorization; | proxy-require; | route; | require; | response-key; | subject; authorization field used by the user proxy to authenticate itself to the server. The hide field is used by the client to indicate that it wants to hide the path composed of the via field from the proxy server or user agent. The max-forwords field indicates the number of times the request message can be forwarded. The priority field is used by the client to indicate the request urgency. The priority-Authorization field is used to indicate the identity of the client to the provincial Authentication Proxy Server. The proxy-Require field is used to identify the proxy sensitive features that the proxy must support. The route field determines the route of the request message. The require field is used by the client to inform the proxy server of the options that the client wants the server to support in order to allow the server to process requests correctly. The require-key field is used to indicate the requirements for keys used by the callee user agent to encrypt the Response Message. The subject field provides an overview of the call or indicates the call nature and can be used for call filtering. (4) The response-header response header field is used by the server to send additional response information to the address specified by request-Uri. Response-header = allow | proxy-authenticate | retry-after | Server | unsupported | warning | the WWW-authenticate proxy-authenticate field must be part of the 407 response, the value in the field provides the authentication system and parameters for the request-Uri proxy. The retry-after field can be used in the 503 response to indicate to the client sending the request how long the service is expected to be enabled. It is used in the 404,600,603 response to indicate when the called is free. The server field contains the software information used by the proxy server to process the request. The Unsupported field lists features not supported by the server. The warning field is used to pass additional information related to the response status. The WWW-authenticate field is included in the 401 response and indicates the authentication system and parameters suitable for request-Uri.