SIP protocol

　　1. Definition : SIP (Session Initiation Protocol, Session Initiation Protocol) is a multimedia communication protocol formulated by IETF (Internet Engineering Task Force, Internet Engineering Task Force)which is an application layer signaling control protocol. A session for creating, modifying, and releasing one or more participants . These sessions can be Internet multimedia conferences , IP telephony , or multimedia distribution . Participants in a session can communicate via multicast, mesh unicast, or a combination of the two.

　　The following is transferred from http://www.cnblogs.com/wangxuchu/archive/2012/10/04/2693372.htmlhttp://www.cnblogs.com/wangxuchu/archive/2012/10/04/2693372.html

1 Introduction

SIP (Session Initiation Protocol) is a plain text application layer protocol similar to the http protocol. SIP can be used to control the establishment, cancellation, and closing of sessions. Mainly can achieve the following functions:

User location: check the location of the end user for communication;
User effectiveness: check the willingness of users to participate in the session;
User capabilities: check media and media parameters;
Establish a session: "Ringing", parameters for establishing a session at the same time between the calling and the called party;
Session management: including the transmission and termination of sessions, modifying session parameters, and requesting services

2. The structure of SIP

The SIP protocol mainly includes the following logical roles: UA, Proxy Server, Register/Location Server, and Redirect Server.

UA: User Agent (User Agent) is similar to the role of the browser in the http protocol. It is the terminal interface for user operations. The user agent needs to meet the requirements of the SIP protocol, but combined with other protocols according to different application scenarios, there will be different implementations. logic. For example, the SIP protocol combined with the H.323VoIP protocol can realize the softphone function. User agents are divided into two logical entities: UAC (UA Client) and UAS (UA Server). UAC sends SIP Request and receives Response, and UAS receives SIP Request and returns Response. A physical device can be both UAC and UAS.
Proxy Server: The role of the proxy server is to forward the Request and Response to other Proxy Servers or UAs. The Proxy Server is divided into a stateful proxy server (Stateful Proxy) and a stateless proxy server (Stateless Proxy). The former will retain a communication transaction. State, the forwarding operation is controlled by a finite state machine, and the latter does not save the state, but only realizes the transparent forwarding operation.
Registration/Location Server: The registration and location server is used to register and locate the UA. The online UA will periodically send SIP messages to the Registration server to indicate the current location of the UA (such as IP address, port number, etc.), and the Registration server will send the information Stored in the database (or hash table), when other UAs send requests to the UA, the location of the UA can be obtained.
Redirect Server: used for redirection, which is logically equivalent to a special function UA.

1. Concept

Session is an important concept in SIP protocol. It is different from session, which occurs in point-to-point communication between two UAs. In layman's terms, it's like two people talking, for example:

A:Hi, my name is Tommy, hello!

B: My name is Elaine, nice to meet you

A: I don't know if you have time tonight, please have coffee

B: I have time.

A: Then at 7:00 tonight at the Chinese Starbucks

B: Well, ok

A: That's settled then, see you tonight.

B: See you tonight.

Usually, one party initiates a conversation. When the other party has no response, or the response is "I'm sorry, I don't know you", "I'm busy and no time right now", the conversation can't start; In a state of early waiting to start; if the response to the Fa is "hello", indicating that the other party is willing to talk to you, the dialogue officially begins. The end of the conversation is usually when one party says "goodbye" or something like, or the other party says "wait a minute" and then "can't talk today", so the conversation is over. For a conversation, both parties to the conversation need to know who they are talking to, and what medium to use for the conversation (such as telephone, QQ, etc.) There will be no confusion. The same is true for the dialogue between two UAs. The dialogue needs to have a start mark and an end mark, and the content of the dialogue is in the middle. Both sides of the dialogue should maintain the dialogue state until the dialogue ends.

2. State transition

Conversations include three states: early, confirmed, and closed.

Dialogs are created by non-failure responses to requests that contain specific methods, specifically a 101-199 response or a 2xx response to an INVITE request will create a response.

A non-final response (101-199) to a request will create an early (early) conversation.
A 2xx final response to a request will put a dialog into the confirmed state, and the dialog entering the confirmed state can initiate a new transaction.
The dialog in the early state will enter the closed state when it receives the non-2xx finalization response corresponding to the request of the dialog. After sending a BYE request in the dialog in the confirmation state, the dialog will also enter the closed state.

3. Conversation information

As mentioned above, the UAs on both sides of the dialogue need to maintain a state for the dialogue, that is, the information of the dialogue. This information is used by the UA to distinguish different dialogues. This information only corresponds to a dialogue on the same UA side, but the two UAs in the dialogue The description information for the same dialogue is not necessarily the same. In fact, in the SIP protocol, the description information for the dialogue between the two parties is different. The UA participating in the dialog needs to use a dialog-ID to uniquely identify a dialog. This dialog-ID is composed of Call-ID, remote-tag and local-tag. At the same time, it needs to know the addresses of both parties, that is, a local-uri and remote-uri, you need to know the order of the dialogue, then you need a remote-CSeq and local-CSeq to mark the order of the dialogue content, etc.

1. Overall structure

After reading the RFC for such a long time, let me talk about my understanding of the communication granularity of the SIP protocol. The communication behavior in the SIP protocol is divided into different granularities. From small to large, it is the transmission of point-to-point sip messages (this point Summarized by myself), sip transactions, sip conversations, and sip sessions. The most basic unit of sip protocol transmission in the transmission of point-to-point sip messages occurs at the Transport Layer, which is to send a sip message to the destination UA (or Proxy) through underlying protocols such as udp, tcp or tls. transport layer. The granularity of the transaction is above the point-to-point sip message transmission, including a series of sip message transmission. The transaction consists of a request, 0 to multiple temporary responses, and one or more final responses, representing a complete request-response process. The dialogue granularity is larger, and a dialogue may contain 0 to multiple transactions from entering the early state to the closed state (the dialogue will directly enter closed when it receives a non-2xx response after receiving 1xx and entering early, otherwise it must go through a BYE transaction to enter. closed state). The dialog should take place at the Transaction User layer, where the user controls the start and end of the dialog. A sip session represents the process of communication between several users and may contain multiple dialog processes.

2. The state machine of the transaction

INVITE Client Transaction

Non-INVITE Client Transaction

INVITE server transaction (INVITE serverTransaction)

Non-INVITE server Transaction

3. Matching of sip message and state machine

Since the sip message received at the transport layer needs to be handed over to the corresponding state machine for processing, the sip message needs to be used in the transaction layer to match the instance of the state machine, and this matching is divided into two categories:

1. The UAC transaction matches the response;
2. The UAS transaction matches the request;

1. UAC transaction matches response

When UAC sends a request, it will create a corresponding transaction. Suppose the request ReqA creates a transaction instance TA, and then if it receives a response RespX, you can check whether the response matches TA by checking whether RespX satisfies the following conditions:

The branch parameter of the top line of the via header field of RespX is equal to the branch parameter of the top line of the via header field of ReqA;
The method in the CSeq header field of RespX is the same as the method in the CSeq header field of ReqA, because the cancel request will create a new transaction but has the same branch parameter as the request to be canceled;

When the above two conditions are met at the same time, RespX matches the transaction instance TA.

2. UAS transaction matches request

When the UAS receives a request, it will create a corresponding transaction. Suppose that the request ReqA creates a transaction instance TA, and then if it receives the request ReqX, it can check whether the response matches the TA by checking whether ReqX meets the following conditions:

The branch parameter at the top of the via header field of ReqX is equal to the top one of the via header field of ReqA;
The value of the sent-by of the uppermost piece of the via header field of ReqX is equal to that of the uppermost piece of the via header field of ReqA;
The method in the CSeq header field of ReqX is the same as the method in the CSeq header field of ReqA;

When the above three conditions are met at the same time, ReqX matches the transaction instance TA.