How to Compare sipX ECS with the Asterisk PBX (sipX vs. Asterisk)

raspgiantsneckServers

Dec 9, 2013 (3 years and 10 months ago)

244 views

How to Compare sipX ECS with the
Asterisk PBX (sipX vs. Asterisk)

We are asked quite often how the
sipX Enterprise Communications System

(ECS)
compares against the
Asterisk PBX

and what criteria should be used to select one over the
other in a given situa
tion or for a specific application. It is not our intent to start a "religious
war" nor do we want to digress into marketing. Given that both projects are open source we
aim at the same overall target: To commoditize real
-
time communications and provide a
credible alternative to otherwise expensive and proprietary systems.
sipX and Asterisk can
also be used t
ogether

and many people have done so for a variety of applications and reasons.


Philosophy

Positioned as a PBX Replacement:


Today still, both solutions are typically used as an IP PBX providing
primarily voice telephony services to an enterprise. Bein
g software
based both solutions scale cost
-
effectively from small deployments to
rather large installations. However, there are significant philosophical
differences between the two:

sipX:

sipX is a native SIP solution. The sipX project team did
not

set

out to primarily build a soft PBX. At the time the IETF started to
standardize SIP, a much more significant idea was at the core of
leading thinker's minds: To establish real
-
time communications as a
core capability of the Internet. Very much like email,
they thought, it
should be possible to exchange real
-
time messages (voice, IM, video)
across the Internet and based on a global addressing scheme
-

the SIP
URI. If you want to send & receive email, you need an email server.
Likewise, if you want to send &
receive real
-
time sessions you need a
SIP Proxy
. sipX, therefore, is a SIP Proxy that when deployed "real
-
time enables" an Enterprise. As a side effect it will also replace the
legacy PBX.

Asterisk:
Asterisk follows a different approach. The primary
appl
ication for Asterisk is to replace the PBX, to provide protocol
interworking (H.323, Skinny, MGCP, SIP, IAX, PSTN) in
environments where this is still required and to offer media
transcoding as it might be needed to interconnect disparate systems.
Asterisk

is
not

a SIP proxy server meant to provide global routing of
SIP sessions. Asterisk is architected as an end system like a phone (the
technical term is a "Back to Back User Agent" or B2BUA). While it
"talks" all the different signaling protocols, the insi
de is a proprietary
system to which all the outside protocols are converted as they enter
Asterisk.

Asterisk recently forked and the group around
openpbx.org

has
defined a
new roadmap

that gives insight into what you should expect
to change.

PBX
Features

Still think standard SIP cannot do all the features and ther
efore some
proprietary tricks are needed? Wrong! The sipX team has proven that a
very feature rich IP PBX can be built based on standard SIP and without
any tricks. Consider this
impressive list of supported PBX features

and we
are sure you will change your mind. Even Music on Hold is now
supported for IETF standards compliant phones. Want to automatically
create a corporate directory, adapt it for different departments,

allow users
to add their own contacts and support speed dial configuration without
requiring your users to use the phone keypad? Want all this centrally
backed up so that it can be easily restored if necessary. sipX release 3.8
will provide all that and m
ore.

When it comes to voice there is almost nothing Asterisk would not allow
you to do, so it seems. However, more often than not it is hard to use and
difficult to find out how it works. And most important: It is fully
proprietary. Being open source an
d supporting the standards are two fully
orthogonal issues. Looking for information on how to configure a feature
often requires quite a bit of searching on the Internet. You have to be
willing to "dig in" and research a topic using forums, the Asterisk ma
iling
lists, or other informal resources. Sometimes different implementations
compete for the same functionality and it is left to the user to find out
which one to use. Adds, moves and changes in a production environment,
therefore, require expert assista
nce. And most likely you heard about the
trouble with the SIP REFER method
-

the easiest way to identify that an
ITSP is using Asterisk is when you cannot transfer a call you received.

Voice
Quality

sipX supports better voice quality

-

straight and simple. The reason is
obvious: In SIP voice or "media" is supposed to be routed peer
-
to
-
peer,
and that's what we do. Consider this: Two r
emote workers call each other.
The call is setup through their IP PBX at headquarters. They are in the
same hotel in different rooms. Where does media go? With sipX media is
routed peer
-
to
-
peer and therefore experiences the least possible delay and
jitter.

This also allows us to fully support Polycom's new HD voice
capability without making any changes to the system. Therefore, sipX
provides the best possible voice quality, always, and there is no limit on
the total number of simultaneously ongoing calls.

Like many first generation IP PBX systems, Asterisk is modelled like a
more traditional TDM PBX where lines ("channels") come into the PBX
that carry voice and signaling. The IAX protocol even explicitly bundles
voice and signaling along the same route.
This not only uses more
bandwidh than necessary, imposes additional delay, injects additional
jitter, and represents a single point of failure, this also severely limits the
total number of calls that can go on at any given time for the system. With
Asteri
sk that number is about 120
-

yes,
only 120
. With HD voice that
number will go further down.

History &
Deployments

sipX:

sipX sta
rted its life as a commercial SIP
-
based IP ECS
(Enterprise Communications Server) solution. It became open
source first in 2004 and therefore is still rather new. At the time
major architectural decisions were taken for sipX it was already
clear that SIP w
ould become the protocol of choice for VoIP both
on the Enterprise and Carrier side. Therefore sipX can be looked at
as a
next generation VoIP solution

that for the first time truly
leverages SIP and follows the standard. sipX is under heavy
development an
d by now has closed the gap to both Asterisk and to
much larger and more expensive systems. The largest known
production installation of sipX currently supports
5,000 users

on a
single HA system with a plan to grow. With the addition of high
-
availability s
ipX will have eliminated any single point of failures in
the call control system and will therefore qualify as a production
system for a mission critical application: voice.

Asterisk:
Asterisk came about when "Mark needed a PBX for his
company and instea
d of buying one decided to build his own".
Asterisk has been an open source project since 1999. At the time
Asterisk was started H.323 still was the dominant VoIP protocol
and therefore a proprietary core was found to best support protocol
interworking bet
ween all the VoIP protocols being discussed at the
time. The Asterisk team even found it necessary to invent its own
proprietary trunking protocl, IAX, to more easily penetrate
firewalls in the absence, at the time, of firewall vendors having had
time to a
dd proxy or ALG support for VoIP protocols. Asterisk is
known to support rather large installations often in conjunction
with the SER SIP router (a SIP proxy). In service provider
installations Astserisk is most often used as a voicemail system.
Home use i
s widespread with Asterisk@Home.

Architecture

sipX

is a fully distributed system that today
consists of 9
independent server components
: Configuration

server, forking
proxy server, authentication proxy server, registrar server, status
server, presence server, call park server, media server, and a
conferencing server. Communications between these servers is
based on standard protocol (sockets) such as SI
P, HTTP and XML
RPC. While all the components of sipX can be installed and run on
one physical server, significant progress has been made towards a
fully distributed system.

All
configuration data

(users, devices, permissions, dial plans,
credentials, gro
up policy, CDR data, etc) are stored in a Postgres
database. For release 3.2 the database and Configuration server
subsystems are tested up to 7,000 users and their devices to ensure
adequate performance.

Media & signaling

are strictly separated as mandat
ed in the SIP
standard. Having media and signaling go through the same server
would not only impose significant performance limitations, it also
creates an unacceptable single point of failure.

A distributed architecture also naturally allows for
load
-
bal
ancing,
performance scalability, and fail
-
over
. In release 3.2 the sipX
project introduced high
-
availability with a fully redundant call
control system (proxy and registrar). Under normal operating
conditions the redundant systems will load share. Registra
tion state
information is automatically and in real
-
time synchronized between
redundant registrars creating
one big system

from a user
perspective. This feature is normally only seen in expensive large
enterprise systems.

Media gateways:

sipX works with a
ny network connected
FXO/FXS gateway from any vendor and allows for flexible rules
based call routing using different gateways in different locations,
including automated fail
-
over in case a gateway is temporarily
unavailable. A special dial plan feature s
upports highly resilient
emergency call routing (E911) at different levels, providing service
even if the sipX server is unavailable. If desired, high
-
quality
gateway PCI cards such as the TP
-
260 from Audiocodes can be
integrated into the same server used
for sipX.

SIP standard:

sipX is 100% SIP standards compliant.

Asterisk

is a monolithic application that
cannot be distributed

across several physical servers. Configuration data is stored in flat
files by default. An option exists to connect different
database
servers at the backend. Communications interfaces are implemented
in "channels" with each channel being responsible for a particular
protocol. E.g. the SIP channel implements the SIP capabilities (one
source file with about 10,000 lines of code).
The internal structure
of Asterisk is proprietary and Asterisk does not implement a native
SIP router. In addition to standard protocols such as SIP, MGCP,
H.323, Asterisk also supports proprietary protocols such as Cisco
Skinny and Asterisk IAX.

Media &
signaling by default go through the Asterisk box

(i.e.
Asterisk sits in the media path). This has advantages when it comes
to the simple (but non standard) implementation of features such as
music on hold or call recording. It also allows implementing
feat
ures independent of the end point's (i.e. phones) capabilities
using old fashioned DTMF tones for feature invocation instead of
e.g. SIP signaling. Requiring media to go through the call control
server has significant disadvantages as well, among them
limi
ted
scalability, additional delay and jitter in the media path, as well
as introducing a single point of failure
. Using the SIP re
-
invite
method SIP
-
to
-
SIP calls can sometimes be re
-
routed around the
Asterisk box under certain conditions but only after the

call first
was established through the Asterisk PBX.

Media gateways:

Asterisk is architected as a one
-
box solution
including gateway PCI cards from Digium. While it can
interoperate with external gateways, the easiest setup is using the
Digium cards.

Management
& Usability

Ease of use and installation

is a critical design goal for sipX. All
system administration and configuration is done using a Web
interface provided by
Configuration Server
. Configuration server is
an integral component of the system and therefore data consistency
is always maintained. The admin should not be required at any time
to use a Linux command line or edit config fi
les. Configuration
server also provides a
Web services API based on SOAP
. In
addition, user & device configuration data can be
bulk uploaded
from a csv file

generated by your favorite spread sheet application.

sipX provides a defined upgrade path that inc
ludes automated data
migration as you upgrade from release to release. In case of
database schema changes automated scripts are invoked to migrate
your configuration data.

The primary admin interface for Asterisk is a
Linux command
line interface

(CLI).

System configuration is accomplished by
editing a large number of text based configuration files. AMP
-

the
Asterisk Management Portal provides a graphical interface to edit
Asterisk configuration files. The level of abstraction provided by
AMP is limited

and the admin still needs to be intimately familiar
with the structure and syntax of the Asterisk config files. AMP
does not allow configuration of all the features in Asterisk and
therefore the admin will have to revert back to editing the config
files d
irectly in some cases. Extreme care has to be taken as direct
modifications of config files and config changes through AMP are
not always kept consistent.

Upgrading Asterisk can be a difficult task as data migration is not
automated and documentation is h
ard to come by.

Because the core Asterisk team has not embraced a Web based
configuration solution several different solutions were created in
the community. AMP is the most visible one developed by a
company in Canada.

Plug &
Play
Mgmt of
Devices

sip
X provides plug & play management for an
increasing number of
peripheral devices

such as phones and gateways. A si
mple XML based
plug
-
in interface is available that can be used to easily add support for
new devices. As such the sipX Configuration server replaces the
management interface provided by the phone or gateway and allows all
configuration to take place remote
ly. A high level of abstraction is
provided where users can be assigned to devices, device and user
properties are managed in groups with inheritance, and the management
capability goes as far as including firmware upgrades for the devices.
Device configur
ation data is
stored and backed up centrally

as part of
the sipX system. Phones use (T)FTP or HTTP to load profiles at boot
time.

Device management is outside the scope of Asterisk with the exception of
some experimental code to manage Cisco phones.

IT
Integration

sipX aims at complete IT integration. While the architectural
framework has been laid out,
some work is still required

to
accomplish this goal. Today sipX

provides a Web Services SOAP
interface for configuration and integration into Web portals. LDAP as
well as POP3/IMAP integration are planned. In addition, the sipX
project still needs to add more comprehensive fault & performance
management.

While Aste
risk does not provide any Web Services integration, it
provides a rudimentaty framework for fault & performance
management of the server infrastructure. Also LDAP integration has
been done in the community. IMAP / POP3 integration is more
problematic and t
here is discussion around a need to
re
-
design the
voicemail system
.

Code
Base

Size of the Code Base:

In s
pite of its younger age, the sipX code base is
about
twice the number of lines of code

as compared to Asterisk
(890,000 vs. 488,000).

Roadmap Planning & Upgrades:

sipX development is driven by a
published roadmap

and releases go through a formal Q&A process before
being released as stable. The sipX project also provides
automated
update procedures for seamless data migration

during release upgrades
of production systems
. Asterisk planning is less formal and more ad
-
hoc
driven by community contributions and a bounty system. Release
upgrades require expert assistance.

Programming Language:

Asterisk is witten in C and does not use XML
for data structures. The sipX Commun
ications server infrastructure is
written in C++. The sipX Configuration server is a Java application. sipX
heavily relies on XML for its internal data structure and a set of related
modern languages and protocols.

SIP Implementation:

sipX is based on t
he sipX SIP stack, a
comprehensive set of libraries that implement the SIP signaling protocol.
In Asterisk the SIP capabilities are concentrated in the SIP channel, which
effectively implements a SIP user agent. The source code concentrates in
a single fil
e,
chan_sip.c
, with about 10,000 lines of code. Given
significant issues with this SIP implementation, several attempts were
made to replace it with a real SIP stack using either reSIProcate or
eXosip2.

Testability:

sipX rigorously implements a unit tes
t framework, which
leads to very high code coverage (>70%). Unit tests are integrated into the
build system and together with automated "smoke" tests as part of every
build assure high code quality even in the development branch. Asterisk
does not use unit

tests.

Documentation:

sipX comes with extensive documentation including
users and admin manuals.
Doxygen

is used extensively to document the
sipX code. Asterisk also comes with lots of documentation, especially on
the user and admin side. Code document
ation is of lower quality if
available at all. Documentation for Asterisk needs to be searched for on
the Web and a fair bit is outdated.

Distribution:

Asterisk is available as a source distribution only. Binaries
are made available by the community for

some Linux distros, but support
is not always consistent and typically lags the source release considerably.
Given the few external dependencies and the rather simple build system,
Asterisk can be built from source by anyone with some Linux
programming kn
ow
-
how. SIPfoundry provides binary releases and single
file installers for sipX together with the source code. The main Linux
distro for sipX is the Red Hat family (RHEL, Fedora Core, CentOS), and
binaries are now available for an increasing number of othe
r distros.

License:

sipX is available under the L
-
GPL license while Asterisk uses
the GPL license. The sipX project encourages commercial use of its
library components as permitted by the L
-
GPL license.