What is OpenSIPS?

There are a number of open source applications available that are used to build IP Telephony solutions. OpenSIPS may not be as well-known as Asterisk, but it is widely used by service providers as a core part of their infrastructure because of its robustness, speed and capacity.

In this article I will review the history of OpenSIPS, explain what it is, what features it offers and its core operational roles. This will include a summary of the many optional modules available within the OpenSIPS project. In a later article, I plan to explore different networking scenarios and examine in more detail the roles that OpenSIPS can play in the infrastructure of an Internet Telephony Service Provider.

Overview and history

OpenSIPS is an open source SIP Proxy program that runs on Linux platforms. The development project strives to provide a product that has plenty of useful features and high performance, while adhering closely to published standards. It is freely available as downloadable source code at www.opensips.org and is licensed under the GNU General Public License (GPL). Details of the license terms can be found here and project documentation is located here.

The history of the project is not simple and it started life in 2001 as SIP Express Router, or SER. In 2004 the team and copyrights were moved to iptel.org which was bought by TEKELEC in 2005. Nominally, the iptel SER project web site still exists today, but since 2006 it stagnated (the most recent News item is dated May 2007) and the feature set described there is now extremely out of date. In 2005 some members of the original core SER development team set up the OpenSER project which appeared to continue where SER left off. At the time, the OpenSER developers spoke of significant underlying structural improvements being made to allow better performance and easier on-going development. The Romanian-based company Voice System has actively supported the project since then, although in 2008 irreconcilable differences within the OpenSER development team resulted in it forking in two directions under different names – Kamailio and OpenSIPS. The split was not very amicable and consequently an online search is more likely to turn up invective than an objective analysis of the differences between the two branches. I cannot offer advice for those wishing to choose between Kamailio and OpenSIPS, but at the time the split occurred I had to pick one and my decision was to go with OpenSIPS. I cannot now remember why.

What does OpenSIPS do and how does it do it?

The primary purpose of any SIP Proxy server is to receive SIP requests, examine and classify them, check that they are valid and then retransmit them to an appropriate destination. Before retransmitting a request, OpenSIPS may alter the request by changing, adding or removing headers and/or changing the primary destination address – the so-called Request URI. It can intercept unwanted requests and return an appropriate rejection response (or it can simply drop unwanted requests if that is more appropriate). Permitted requests are relayed to a destination which most often is determined directly from the Request URI, but may also be another Proxy server. OpenSIPS is also able to fork requests to multiple destinations – either in parallel or one at a time.

A SIP Proxy server must also be able to handle the responses that are sent back to it. An example of a SIP request is the INVITE request which is used to set up a call. The called device will usually send a series of responses such as 100 Trying, 180 Ringing and finally 200 Ok to show that the call has been answered. The SIP Proxy must relay the appropriate responses back to the original client device that initiated the request, but it is also allowed to modify the responses if appropriate.

In addition to this role as a routing engine, OpenSIPS is also able to act as a Registrar server. In this role, it accepts and processes REGISTER requests sent to it from time to time by remote devices. These requests are used to update a location database which stores information about the network location and contact details for various SIP User Agent devices. [A SIP User Agent or “UA” is the jargon used to describe SIP equipment such as IP phones, softphones, IP-PBX’s etc]. OpenSIPS is then able to lookup details in its location database whenever it needs to route a request to a registered device.

OpenSIPS generally runs as a background service (or daemon) listening for incoming SIP requests. By default it listens for UDP requests on port 5060 on all network interfaces, but the defaults can be changed. The behaviour of OpenSIPS is determined by a script read from a configuration file. The format of the script is text rather like a programming language – in some respects the syntax quite closely resembles the C programming language. OpenSIPS must have a script before it can run and a default script is supplied as part of the install package. The file is called opensips.cfg and is typically stored in /etc/opensips. The script has a module initialisation section at the beginning, followed by one or more “route blocks” which in many ways resemble subroutines in a programming language. The programmable nature of this control script is what gives OpenSIPS its enormous flexibility, but it also makes for quite a steep learning curve for beginners. The language supports a large number of core functions and variables plus functions exported by the optional modules, making it relatively easy to perform a wide range of manipulations on the SIP messages as they pass through.

It is very common to link the OpenSIPS control script to a MySQL database (other databases are also supported). This allows the script to reference information stored in tables that may be altered and read by other applications. For example, a list of user ID’s and passwords is stored in the subscriber table and, when a device registers, its location and contact details are stored in the location table.

Who uses OpenSIPS?

OpenSIPS is used by many prestigious VoIP service providers. These service providers have no reason to make it known, but with the help of a simple SIP ping utility I was able to identify the following (in no particular order): Google Voice, Magrathea, Voiptalk, OrbTalk, Gradwell, Voxbeam, Freespeech and Sipbroker. So if you choose OpenSIPS, you will be in good company.

How does OpenSIPS differ from Asterisk?

The inescapable question! This article is intended to be a review of OpenSIPS and not a comparison with Asterisk so I have relegated this discussion to a different article.

Features and capabilities

The original feature set of SER and OpenSER, while adequate and competent, was not wide ranging. The emphasis was more on performance and conformance than on features. However, the product has been under continual development for several years and now includes a wide range of optional modules. The range of features available through the optional modules is now extensive enough to make OpenSIPS a serious alternative to the SBC’s (Session Border Controllers) available commercially at eye-watering prices.

The following tables show a selection of the modules categorised according to their complexity and how essential they are to the core operation of the product.

Commonly required “core” modules

Module	Description
DB_MySQL	Allows OpenSIPS to retrieve data from and write records to a MySQL database. The DB server can run on the same server as OpenSIPS or can be accessed via the network
Dialog	Makes OpenSIPS ‘state aware’ for the calls it is proxying. This module is a pre-requisite for many other modules and features allowing control of maximum call duration. It also makes many other options possible such as categorisation of calls, limits to the number of simultaneous calls, proper formation of CDR’s and easy tracking of call related options like NAT traversal and SIP tracing.
Group	Allows registered devices to be allocated to groups. Membership of a group can be used to control behaviour or to apply constraints to the services available to each user.
Permissions	Another module that enables control of the services available to different users, but this module is able to categorise requests based on the source IP address
Domain	Allows user devices and SIP requests to be matched to various pre-defined SIP domains
Usrloc	Core component used for device registrations and to maintain a location table
Registrar	Core component used for device registrations and to maintain a location table
Textops	Allows basic string manipulation and testing, searching, replacing within text strings and variables
TM	Core module used to statefully handle SIP requests
URI	Provides core functions used to check if a device is correctly authenticated
SL	Core module used to send stateless replies to some SIP requests
RR	Core module used to add Record Route headers to SIP requests

Very popular additional modules and options

Option/Module	Description
Control Panel	Web based user interface to manipulate and view the data tables associated with several other popular modules including Call Data Records
Call Data Records	A record of each call showing time, date, called number etc
SIP Trace	A trace of the raw SIP messages written to tables for later viewing
Alias DB	Table based aliases – can also be used to generate a list of multiple alternate destinations when combined with the Parallel Forking option
Pike	Flood detection. Helps prevent DoS or brute force password guessing attacks
Load Balancer	Uses table based descriptions of end points and resources to distribute calls based on the resources needed. Includes option to ping for server availability.
Dispatcher	Similar to Load Balancing, but uses pre-defined groups rather than resource descriptions for the server end points.
Options	Allows OpenSIPS to answer Options requests
Parallel Forking	Using a table lookup or static rules, a single SIP Invite request can be forked to multiple destinations in parallel or series.
SST module	SIP Session Timers. Used to detect and terminate dead calls.
ENUM module	Support for ENUM routing
NAT Helper	For far-end NAT detection and fixing headers
MediaProxy	Allows remote NAT’d end points to make a successful RTP connection through an intermediate Media Proxy server

Advanced and more complex modules and options

Option/Module	Description
Dynamic Routing	A powerful and flexible solution for controlling the routing of calls based on prefixes, caller groups, times and priorities. It can be used for inbound or outbound traffic, is able to select gateways and provide serial forking. Includes probing of servers to test if a route is available.
Presence	Control BLF lamps to show the status of other extensions and devices
Exec	The Exec module allows OpenSIPS to interact with external services. For example, it can send an HTTP request to an application server to get routing information or to report call events
SNMP Stats	Allows your OpenSIPS server to be monitored using standard SNMP management tools such as PRTG or Cacti.
Radius	Allows OpenSIPS to link to a Radius server for authentication and call accounting (an alternative to CDR’s).