Introduction to Osip2 and eXosip protocol stacks

Osip2 is an open-source sip protocol stack, which is not frequently written in C language in open source code. It has the characteristics of being short and concise, focusing on the underlying parsing of sip makes it more efficient.

EXosip is an extended protocol set of Osip2. It partially encapsulates the Osip2 protocol stack, making it easier to use.

I. Introduction

Osip2 is an open-source sip protocol stack, which is not frequently written in C language in open source code. It has the characteristics of being short and concise, focusing on the underlying parsing of sip makes it more efficient. However, the disadvantage is also obvious. First, the availability is poor, and there is no good api encapsulation, which makes the upper-layer applications break down when calling the protocol stack. Second, only the Protocol process at the transaction level is parsed, the lack of resolution of call, session, dialog, and other processes also increases the difficulty of use. Thirdly, the lack of thread concurrent processing mechanism makes it limited in processing capabilities.

EXosip is an extended protocol set of Osip2. It partially encapsulates the Osip2 protocol stack, making it easier to use. EXosip adds resolution for call, dialog, registration, subtasks, and other processes, making it more practical. However, eXosip is limited to UA implementation, making it extremely difficult to use it for applications such as registrar and sipserver. In addition, it does not add a mechanism for concurrent thread processing. It only supports audio and does not support video and other data formats.

In general, Osip2 and eXosip protocol stacks are still good choices for implementing the Sip protocol. Of course, you need to add more content according to different requirements.

Ii. Composition of Osip2 protocol stack

The Osip2 protocol stack can be roughly divided into three parts: the syntax analysis of the sip protocol, the Process Analysis of the sip protocol and the protocol stack framework.

1,Syntax analysis of the Sip Protocol: Mainly osipparser2. Currently, RFC3261 and RFC3265 are supported for sip protocol messages, including INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, publish y, MESSAGE, REFER, and INFO. PRACK defined in RFC3262 is not supported.

Follow the RFC3264 offer/answer mode for SDP. Syntax analysis with SDP.

Supports MD5 encryption and decryption algorithms. Authorization, www_authenticate, and proxy_authenticate are supported.

2,Process Analysis of the Sip protocol:

It is mainly the osip2 part. It describes the process based on RFC3261, RFC3264, and RFC3265, and implements sip resolution at the transaction layer.

Transaction refers to the interaction process between the sender and the receiver, composed of requests and responses. Requests are classified into Invite type and Non-Invite type. Responses are divided into response and validation. A response indicates that the response only indicates that the other party receives the request. After the request is processed, a confirmation response must be returned. There are 1xx response types, and 2xx, 3xx, 4xx, 5xx, and 6xx response types. A transaction consists of one request, one or more response types, and one validation response.

Transaction can be divided into four types based on different requests and different sending/receiving: ict, nict, ist, and nist.

Ict refers to Inviteclienttransaction, which is the initiator of the session invitation.

Nict refers to Non-Inviteclienttransaction, which is the initiator of a Non-invited session.

Ist refers to Inviteservertranaction and the receiver of the session invitation.

Nist refers to Non-Inviteservertransaction, and refers to the recipient of a Non-invited session.

Each type of transaction has its own state machine. The Osip2 protocol stack processes all sip events based on the state machine. Therefore, this part is the core of the entire protocol stack. However, because Osip2 only implements the transaction layer, it can ignore the complexity of call, registry, and other applications, which is quite simple, this makes it necessary for the application that needs to use it to process its own logic. It must be noted that the resource of transaction is released by the protocol stack in Osip, but is released by the application used in Osip2.

The following describes the state machines of the four transactions in a time sequence diagram. It only describes the transition between States, ignores the called processing functions, and simplifies many events without state transformation. That is to say, the events defined in each State are not completely shown in the figure. Do not think that these events are not defined or are not processed in this state.

In the figure, the status name is displayed in the box, and the event name that triggers the status change is displayed on the arrow. Events in the same status do not have time sequence relationships.

3. protocol stack framework:

A framework does not refer to a part of code, but to its composition. There are three main parts: the underlying socket receives/sends, the inter-module communication pipeline, and the upper layer calls the api interface.

Osip2 does not support receiving/sending of underlying sockets. It is implemented by eXosip and only supports UDP link connections.

Inter-module communication pipelines include the transaction message pipeline and jevent message pipeline. The message pipeline of Transaction is a component that drives its state machine. By continuously receiving remote signaling from the underlying socket, or calling commands from the upper layer, transaction is driven based on the above state machine mechanism. The Jevent message pipeline is implemented by eXosip and is used to report underlying events so that the calling program can process events of interest.

There are roughly two types of upper-layer called api interfaces: The call interface of the sip protocol and the call interface of the sdp protocol. EXosip encapsulates most of the interfaces called by the sip protocol. Generally, you do not need to directly call the interface functions of osip2. There are many interface functions, which are not detailed here. For the function definition, see the comments in the source code section.

Iii. Analysis of eXosip protocol stack

EXosip is the encapsulation and call of the Osip2 protocol stack. It implements most of the functions of a single sip terminal, such as register, call, And subregister.

EXosip uses a UDPsocket socket to receive/send the underlying sip protocol. It also encapsulates the interpreter of the sip message.

EXosip calls the transaction processing function of Osip2 through regular round robin, which is the core of the protocol stack operation. By adding/reading the transaction message pipeline, the transaction state machine is driven so that the remote sip signaling can be reported to the calling program, and the feedback from the calling program can be sent back to the remote end through the sip signaling.

EXosip adds timeout processing for each type of transaction to ensure that all resources can be recycled and will not be exhausted.

EXosip uses the jevent message pipeline to notify the calling program of events at the underlying layer. The calling program can obtain the events of interest and perform relevant processing as long as it reads the message pipeline.

Important EXosip applications include j_cils, j_subscribes, j_notifies, j_reg, j_pub, osip_negotiation, and authinfos. J_cils corresponds to the call linked list and records all active calls. J_reg corresponds to the registration linked list, which records registration information of all current activities. Osip_negotiation records the local capability set for capability exchange. Authinfos records the required authentication information.

Edit recommendations]