OpenSIPS and Asterisk are both open source projects and both are used for Voice over IP. However, they perform quite different roles, have different capabilities and different strengths and weaknesses. This article reviews how they are so different and considers what role each product can play in the infrastructure of an Internet Telephony Service Provider solution.
Fundamental differences
A succinct, but slightly technical, distinction between OpenSIPS and Asterisk is that OpenSIPS is essentially a SIP Proxy Server while Asterisk is essentially a Media Server (for a detailed explanation of these terms click here). This means that OpenSIPS is not normally the final end-point for a voice call; instead it relays the call control signals from one server to another. On the other hand, Asterisk does terminate calls and, even if it appears to relay a call onward to another destination, it does so be creating a new call and linking the audio streams to make the two calls appear as one – this behaviour is referred to as a “Back-to-Back User Agent” or B2BUA for short.
There are several other important differences including:
- OpenSIPS has no inbuilt media capabilities – it cannot record or play speech or music
- Asterisk has media capabilities which means it can be used as an IVR (with menus of options for callers to select using their keypad) or as a voicemail server etc.
- Asterisk has many built-in features that allow it to act as an IP-PBX or business telephone system. It can also act as a conference server. OpenSIPS does not have these capabilities.
- Asterisk can act as a gateway between different telephony technologies (including ISDN) whereas OpenSIPS is only a SIP Server.
So, you may think OpenSIPS sounds like a poor relation of Asterisk with fewer capabilities, but in fact these products are just not designed to do the same job. Where OpenSIPS scores is in its robustness, flexibility, adherence to SIP standards and, above all, its speed and call capacity which are in a completely different league to those of Asterisk.
Links to more detailed point-by-point comparison tables can be found under the heading of “further reading” at the end of this article.
When to choose Asterisk
Asterisk can interconnect with legacy telephony technologies such as analogue (FXS ports where handsets are to be connected and FXO where a line from the Telco needs to be connected) and ISDN. Combined with its built-in PBX features, this makes it very suitable for customer premises as a replacement for, or add-on to, an existing PBX or business telephone system. Its voicemail, IVR and conferencing capabilities make it a popular choice for hosted service providers and its ability to bridge different telephone technologies means it can also be used as a PSTN gateway, for example where a service provider wants a resilient infrastructure with multiple disparate paths connecting their services to the public telephone network.
For many applications, especially as corporate end-user equipment or CPE, Asterisk is very competent. In these situations, I would generally recommend using a distribution that includes a web GUI interface (FreePBX, PBX-in-a-flash, Elastix or similar). However, Asterisk has some weaknesses and limitations that become more apparent as your solution is scaled up. For a telephony service provider, the call capacity of a single Asterisk server – typically up to 200 simultaneous calls – is likely to be too low. In a complex network environment, its slightly simplistic solutions for near-end and far-end NAT traversal may not work for some situations or for some makes of IP phone or ATA’s. It is a popular target for hackers, who know all its loopholes and weaknesses. From experience, I also have doubts about its ability to stand up to denial of service attacks. It does not support multiple SIP registrations to the same account.
When to choose OpenSIPS
OpenSIPS is frequently used by Internet telephony service providers (ITSP’s) as a “front door” – a connection point for a wide range of SIP devices and SIP trunks. In the right hands, it can be configured to cope with a range of different network architectures and can identify and fix non-standard SIP implementations as well as being able to fix the SIP headers for remote devices operating behind NAT. It can be used to load balance incoming calls to a group of media servers- possibly Asterisk servers. For outbound traffic, it can select different carriers using least cost routing (LCR) combined with failover in case the preferred route is unavailable or already at maximum capacity. Unlike Asterisk, it correctly handles multiple registrations to the same account.
The flexibility of OpenSIPS derives from its use of a configuration file containing a control script written like a computer program – the language is similar to C. This allows the application to inspect the contents of each SIP request down to a very low level, looking at headers, source address, contact address, user-agent, call ID, etc. The SIP requests can be modified, forwarded, forked, dropped or sent a response. In this way it is easy for OpenSIPS to distinguish between normal traffic and illegal requests or requests designed to identify open ports on SIP servers (e.g. friendly-scanner). This ability makes OpenSIPS even more suitable as a “front door” for access to to your other SIP-based servers – it has the ability to recognise and drop the most common port-scanning requests, the capacity and robustness to withstand DoS attacks and the flexibility to let you add rules for special cases and exceptions. What I am describing is, almost, a SIP firewall. Viewed in this light, OpenSIPS is a direct alternative to the so-called Session Border Controllers (SBC’s) that are increasingly being promoted as a “must-have” component in corporate VoIP solutions.
When combined with Mediaproxy from AG-Projects, OpenSIPS is able to solve problems of far-end NAT traversal in a more refined manner than Asterisk. The structure and content of external data referenced by OpenSIPS at run time (e.g. tables in a MySQL database) is better defined than the equivalent within Asterisk. OpenSIPS adheres more closely to the RFC’s that define how SIP should behave and it can support SIP over TCP or UDP as well as secure SIP over TLS. However, on the minus side, OpenSIPS cannot do codec translation (transcoding) or use telephony cards to interface to ISDN, analogue etc, it does not support IAX or H323, and it has no media capabilities for recording, playing voice files, mixing, conferencing, text-to-speech or speech recognition.
Teaching OpenSIPS new tricks
As a product, OpenSIPS does not stand still. Version 1.7 was released in the summer of 2011 and further releases are promised soon. By virtue of the Dialog module, it is now fully state aware which has allowed many improvements including better Call Data Records (CDR’s) and the ability to limit the number of simultaneous calls allowed to a particular end point. The developers have also added a B2BUA module. In part the justification for this was to allow improved topology hiding – the process whereby the addresses of some of your telephony servers can be hidden from the external users. This may be of benefit where OpenSIPS is required to act as a kind of SIP firewall or SBC, but it seems somewhat out of character to me, especially as one of the original oft-quoted differences between Asterisk and OpenSIPS was that Asterisk, unlike OpenSIPS, is a B2BUA.
Working together
In my experience, there are great benefits to be gained from using a combination of OpenSIPS and Asterisk. They complement each other well, especially for the design of a secure, scalable, high volume hosted telephony solution. OpenSIPS can be used as the main portal and can load balance incoming SIP requests to multiple Asterisk boxes. In this role, OpenSIPS is also able to protect the Asterisk servers from the majority of port scanning and password guessing intrusions. Another – or possibly the same – OpenSIPS server can route outbound SIP requests to carriers using LCR. The outbound routing can be augmented with automatic probing of routes to monitor for faults so that traffic can be redirected to another destination when a fault is detected.
Our experience has shown that OpenSIPS combined with Asterisk presents some new and interesting challenges. For example, you have to decide if registrations are to be made to OpenSIPS only, Asterisk only or to both. Furthermore, authentication challenges and their responses, when initiated by Asterisk, must be allowed to pass through OpenSIPS in a transparent manner. Other issues we have solved at Smartvox include proper handling of keep-alive packets, SIP session timers, routing and SDP address fixing for servers behind NAT or in a DMZ, address substitutions for mixed carrier connections (some carriers using private peering and others on the Internet), fixing of non-symmetric SIP ports for Cisco handsets, Asterisk SIP timer issues, activation of message waiting lamps and presence. We are always happy to gain new clients and take on new challenges, so please get in touch to discuss your project.
Further reading
When this article was first written, I included a cross-link to an excellent point-by-point comparison between OpenSIPS and Asterisk published on the web site of “VOIP Today”. Unfortunately, that link no longer works. The next best alternatives I could find are:
From Orbtalk
From Andrew Prokop
Another point-by-point comparison was written in 2008 in an article that I believe should be attributed to Flavio Goncalves (although the same text has since been copied and re-published many times by others pretending it is their own work). Here is a link to the article.
Thank you very much for sharing this information. It is exactly what I needed. Excellent article!