2016 International Conference on Information Systems Engineering

An Elastic VoIP Solution based on OpenStack

Victor Gonzalez Chamorro Carlos Nuez Castillo Fabio Lopez-Pires

National University of Asuncion National University of Asuncion Itaipu Technological Park
Conexion Group NextGS Consulting National University of Asuncion
Asuncion, Paraguay Asuncion, Paraguay Asuncion, Paraguay
victor.gonzalez@conexiongroup.com cnunez@pol.una.py fabio.lopez@pti.org.py

AbstractNowadays, a datacenter infrastructure with static al- service and losing quality of communications. To solve a
location of resources could be a bottleneck towards a high- saturation problem, resources of the datacenter infrastructure
quality network service due to growing and unpredictable could be expanded by acquiring new hardware. The mentioned
demands for resources by modern applications. Additionally, approach for solving saturation could result in under-utilization of
an efficient utilization of the available resources could represent available resources for long periods of time [4].
economical benefits to service providers. In this context, Voice As a novel approach, VoIP solutions could be designed
over IP (VoIP) service providers must address resource considering different cloud computing service models, where the
management problems such as: (1) efficient utilization of adaptation of traditional applications to cloud computing
available resources and (2) maintain high quality of service,
environments could be considered as a main challenge. In
considering particular requirements of the communication
business. VoIP solutions could be designed considering different
cloud computing [5] a new way of using the resources of
cloud computing service models, where the adaptation of infrastructure, applications and services is proposed. The main
traditional applications to cloud computing environments is a idea is that each of the resources may be consumed according to
main challenge. As an innovative use of Infrastructure as a the particular demand in a given instant of time.
Service (IaaS) interfaces, this work presents a cloud-based Cloud computing model presents new opportunities for an
elastic VoIP solution considering its implementation on an efficient management of available resources. It offers on-
industry-leading cloud platform such as OpenStack. In order demand services where the supplied resources may be virtual
to validate the proposed solution, several experiments with machines (VMs), software services or an applications plat- form,
different workloads were performed. Experimental results commonly known as Infrastructure as a Service (IaaS), Platform
show that the proposed elastic VoIP solution can efficiently use as a Service (PaaS) and Software as a Service (SaaS). Particularly,
available resources and dynamically scale according to service IaaS service model, allows to offer on-demand components to
workload demands while maintaining a high-quality of service. build a computing infrastructure commonly composed by: VMs,
interconnection networks and storage.
KeywordsElastic Voice over IP, Infrastructure-as-a- VoIP solutions could be designed considering different cloud
Service, OpenStack, Kamailio. computing service models, where the adaptation of traditional
I. INTRODUCTION applications to cloud computing environments is a main
challenge. As an innovative use of IaaS interfaces, this work
Voice over IP (VoIP) is a group of technologies for de- presents a cloud-based elastic VoIP solution considering its
livering voice across a computer network over the Internet implementation on OpenStack [7]. The VoIP solution pre- sented
Protocol (IP) [1]. The voice signal is sent digitally in IP packets, in this work exploits three of the fundamental character- istics of
instead of sending it in digital or analogical forms through the cloud computing model [8]. First, an on-demand self-service
circuits as the way that traditional Public Switched Telephone makes the resource capacity of the infrastructure appear infinite
Network (PSTN) lines do [2]. Currently, several protocols that to users (i.e. a process could supply resources, such as
implement VoIP are available, being the Session Initiation computing time or storage automatically and without the need for
Protocol (SIP) the most implemented [3]. human interaction with the service provider). Sec- ond, designing
The SIP protocol architecture is commonly composed by solutions that allow a rapid elasticity, resources may be provided
the following components: (1) SIP Proxy, (2) IP Network and and released automatically to quickly scale according to the
(3) clients. The SIP Proxy is an intermediate point between current demand. Third, exploiting broad-band network access,
users of the VoIP solution and allows calls to be made between resources are available through a network and may be accessed
them. The IP network, which can be private (LAN) or public by standard mechanisms, promoting access for clients through
(Internet), is where the SIP packets flow. Clients (a.k.a multiple heterogeneous platforms.
endpoints) make calls through the SIP Proxy [3]. It is important to consider that adapting applications by
Although traditional VoIP solutions reduce costs of com- decomposing software components into micro-services could
munications in general [3], considering that clients no longer improve high-availability and resilience of applications.
depend exclusively on a private PSTN telecommunications In summary, the main contributions of this paper are:
company, currently several problems must be addressed due
to growing and unpredictable demands of multimedia appli- An elastic VoIP solution based on OpenStack for the
cations as VoIP. VoIP service providers must address resource efficient utilization of available resources and dynami-
management problems such as: (1) efficient utilization of cally scale according to service workload demands while
available resources and (2) maintain high quality of service. maintaining a high-quality of service.
Designing a VoIP solution based on static allocation of A performance evaluation that shows the correctness of
resources could be a bottleneck towards a high-quality VoIP the proposed VoIP solution and its effectiveness solving
service. In a high workload demand, resources of the SIP main resource management problems of VoIP providers.
Proxy could be saturated and consequently, reducing its ca-
pacity to serve new incoming communications, degrading the

Unrecognized Copyright
2160-1291/16 $31.00 2016
Information
IEEE 43
DOI 10.1109/ICISE.2016.8
 The remainder of this paper is organized as follows: Sec-
tion 2 describes the main components of a traditional VoIP
solution, while Section 3 presents the proposed elastic VoIP
solution. Section 4 summarizes experimental results. Finally,
conclusions and future work are left to Section 5.
II. TRADITIONAL VOIP INFRASTRUCTURE

SIP is a signaling standard defined by the IETF [9], to

create, modify and finalize sessions (e.g. voice, conferences
or video calls) among one or more remote clients across an IP
network. Although SIP is a peer-to-peer protocol,
telecommunications companies (a.k.a. telcos) implement VoIP
solutions considering servers to offer their services of routing,
user localization, user authentication, authorization and other
services commonly offered by telcos.
To provide VoIP services, telcos usually have a SIP Proxy
Server that performs the necessary functionalities for the
interconnection between clients. While several possible archi-
tectures in SIP exist, this work focuses on the client-server
architecture, and calls are established as described below.
Previously, Alice and Bob are registered in SIPProxy.com,
thus the latter has the information to locate them in case of
receiving a call. For this case, Alice wants to call Bob, so she
sends a call request to SIPProxy.com. The SIP Proxy Service
at SIPProxy.com will look up Bobs address on its localization
Figure 1. High-level architecture of the proposed elastic VoIP solution.
table. Then, it will consult its routing table and send the call to
Bobs location. Bob receives the notification of an incoming
OpenStack administrates compute, storage and network re-
call. Then, Bob answers the call and a notification is sent
sources in a cloud infrastructure, providing dynamic allocation of
to SIPProxy.com. Alice is notified that Bob has answered the
resources to VMs that are instantiated. It is composed by five
call and voice communication can be established. While the
main services: (1) Nova, (2) Glance, (3) Neutron, (4) Swift and
call is established, there is a voice flow that travels
(5) Cinder. Nova, manages computation and network; Glance,
encapsulated in Real-time Transport Protocol (RTP) packets
administrates and provides VM images; Neutron, manages
[10], a process that intensively uses CPU resources. Finally, to
advanced network resources. Finally, Swift and Cinder manage
finish the communication between Alice and Bob, an exchange
storage resources.
of signaling packets occurs that end the call.
The above mentioned services lack two important require-
The above described process occurs for each established
ments that must be accounted for if we need to automate
call, possessing two search sub-processes to locate the user
provisioning of resources with minimum or null intervention of
and then to route the calls, and for the management of the
a human operator as required in the proposed elastic VoIP
RTP packets. With a high volume of calls, these processes
solution. These are available automatic provisioning and
can generate a high CPU utilization in the SIP Proxy Server.
monitoring of VMs according to the utilization of monitored
If CPU utilization reaches the physical limit of the server, the
resources. To achieve this automatic methods, two projects
new incoming calls will not be served correctly, degrading the
created as part of the OpenStack project are recommended:
quality of the VoIP service.
Ceilometer [12] and Heat [13], allowing resource monitoring,
III. ELASTIC VOIP INFRASTRUCTURE alarm creation based on monitored resources and execution of
actions for automatic provisioning based on alarms.
In this section, the required infrastructure to implement an Ceilometer is a project whose main objective is to provide
elastic VoIP solution with an auto-scaling scheme is presented. an infrastructure for the recollection of information within the
A brief introduction of each component that comprises the OpenStack platform. It was designed so that distinct motors that
infrastructure is presented while the proposed architecture for collect data, have just one source of recollection and
the elastic VoIP solution is introduced. Finally, a detailed transformation of this data, having a way to charge for the
description of the interaction between components of the utilization of resources. Ceilometer can publish information
proposed solution is also presented. for monitoring, debugging, graphic tools that show resource
A. Background consumption in real-time or tools that monitor the utilization of
resources to take actions based on the registered data.
A cloud computing service model as IaaS focuses on
Additionally, it has the functionality to create alarms based on
providing resources such as: VMs and virtual storage blocks,
certain rules defined on the monitored data (e.g. CPU usage,
on-demand and abstracting those virtual resources from a set
RAM usage, disk storage usage, etc.). The monitored data is
of physical servers commonly installed in cloud datacenters.
compared with certain defined thresholds, that if surpassed,
A VoIP solution based on IaaS could be designed considering
trigger an alarm and send a notification to all agents that are
dynamic allocation of resources, presenting benefits to solve
registered to receive it. In the context of this work, Ceilometer
the resource management problems previously mentioned in
was configured to collect data on CPU consumption, creating
Section 1. In this work, an elastic VoIP solution implemen-
alarms for certain consumption thresholds (see Section IV).
tation based on OpenStack is presented. It is important to
Heat is an orchestration service that allows the creation of
mention that OpenStack is considered the open-source de-facto
VM instances, virtual networks and other resources of- fered
standard for IaaS system implementation [11].

44
by OpenStack in an automated manner. Heat provides
orchestration based on templates that describe the particular
cloud service to be instantiated, executing commands with a
programming interface or Application Programming Interface
(API) provided by OpenStack. The templates are configuration
files where rules of how to execute the orchestration auto-
matically are described. Heat manages primarily infrastructure
resources, but available templates also allow the integration of
other external tools such as Ceilometer Alarms and automa-
tized administration or configuration of VMs. In the context
of this work, Heat was configured together with Ceilometer,
to instantiate new VMs for the elastic VoIP solution.
To deploy the elastic VoIP solution, the following systems
were considered: (1) Kamailio [14] and (2) RTPProxy [10].
Kamailio is an open-source SIP Server for implementing SIP-
based services such as: SIP Proxy, among others. It is
commonly used by large telecommunications companies for
end users, as well as between companies for interconnections
known as carriers. In this work, it was used as a route and
load balancer, as described next in Section III.B. Additionally,
RTPProxy is a media proxy server that manages multimedia
traffic (e.g. voice, video or both), acting as an intermediate
point in the flow of multimedia packets. The RTPProxy allows
the optimization of the flow of RTP multimedia packets, the
recollection of information about the quality of the established
communication, among other functions.
RTPProxy was used as an intermediate point for the voice
communication between the clients (see Figure 1).
B. Proposed Architecture
As presented in Figure 1, the proposed elastic VoIP solution
is based on the IaaS service model implemented on OpenStack
as a cloud operating system. The VoIP system in provisioned
as VMs in the IaaS cloud, providing IP telephone service.
OpenStack administrates the virtualized resources of compu-
tation, networks and storage that are used to deploy the set of
VMs that finally perform the work of the proposed elastic
VoIP solution. Besides managing the virtualized resources,
OpenStack also manages monitoring and alarms (metering)
with Ceilometer as well as manage automatic provisioning of
required resources by means of alarms with Heat.
In the IaaS environment the VoIP solution is decoupled as
specialized servers as described as follows:
The Kamailio Load Balancer (KLB) receives the SIP signal-
ing messages and resend them distributing the load between
one or more instances of Kamailio Routers (KR). The KLB
also has a monitoring and registration agent of each KR that
discovers which KR is available to receive calls.
Kamailio Routers (KRs) ensure processing, routing and
maintenance of the states of all made calls. It is worth
highlighting that each KR also possesses a registration agent.
Considering that KRs represent the most utilized components
in the proposed architecture, the concept of horizontal elas-
ticity (i.e. the ability of cloud services to dynamically adjust
the number of VMs [15]) is applied to this layer in order to
effectively attend new incoming calls according to required
demands without degrading the quality of the VoIP service
and efficiently use available resources. Initially only one KR
instance is instantiated, but considering the alarms configured
in Ceilometer (see Table I), Heat scales-up the number of KR
instances when KR instances are saturated (e.g. more than 75%
of CPU utilization for more than 2 minutes) or scales-down
the number of KR instances when KR instances are idle (e.g.
less than 5% of CPU utilization for more than 3 minutes).
Finally, there is a MySQL Database that persists the routing
information. This information is used for each KR instance
45
to manage the existing routes for each particular destination. In
the next section details of the monitoring and registration agents
exclusively developed as a contribution for the proposed elastic
VoIP solution are presented.
C. Monitoring and Registration Agents
Exclusive contributions of this work are the monitoring and
registration agents that are executed in the KLB and KR
instances as part of the proposed VoIP solution.
TABLE I. EXAMPLE OF A CEILOMETER ALARM LIST
Name State Enabled Condition
cpu-alarm-high OK True cpu-util 75.0 during 2 60s
cpu-alarm-low OK True cpu-util 2.5 during 3 60s
Figure 2. Experimental environment for the proposed VoIP solutions.
These agents were designed and developed considering that
no tools that fulfill required functions for an elastic utilization of
KRs (i.e. active KR instances management in KLB) were found.
It should be mentioned that both agents were developed using the
Python programming language.
The KLB agent, awaits registrations originated from KR
instances. Once a registration is received, it is added to its
internal routing table so transactions may be sent to it during
load balancing. This agent constantly sends monitoring messages
to each registered KR to know if they can keep receiving calls. If
no response is received, the KR is deleted from the KLB routing
table.
The KR agent is executed when the instance is ready to
receive calls, sending a registration message to the KLB, so
that it may include it in its routing table. This agent also awaits
monitoring messages, to inform that it is still functioning and
ready to receive transactions.
IV. EXPERIMENTAL RESULTS
This section summarizes experimental results obtained in
several experiments with different workloads, performed for
validating that the proposed elastic VoIP solution can effi- ciently
use available resources and dynamically scale accord- ing to
service workload demands while maintaining a high- quality of
service.
To perform these experimental tests, the proposed elastic
VoIP solution was compared against a traditional VoIP solution
(see Section II) with static allocation of resources. To perform
the experiments on both described solutions, the SIPP [16]
tool was considered as a traffic generator that uses the SIP
protocol. The settings of the SIPP tests are defined in XML
format, acting as generator and receiver of traffic.
The configuration of the experimental environment for the
traditional VoIP solution is presented in Table II. The selected
settings for this environment include a call generator (SIPP), a
VoIP server with Kamailio and RTPProxy, MySQL database and
a call receptor (SIPP). The configuration of the experi- mental
environment for the proposed elastic VoIP solution is presented
in Table III. In the elastic VoIP solution, the KR instances timely manner. However, the elastic VoIP solution could serve
increase or decrease dynamically according to the amount of 100 % of the requests, without further inconvenience.
calls, causing the allocated resources to vary in order to
adapt automatically to the demand. TABLE V. EXPERIMENTAL RESULTS FOR THE ELASTIC VOIP SOLUTION IN
EXPERIMENT 1
TABLE II. TRADITIONAL VOIP SOLUTION CONFIGURATION CPS # VCPU RAM Min CPU % Max CPU % # Completed
50 1 1 49 56.42 100
Resource Description
100 2 2 (84;1.5) (92.15;1.5) 100
Server 3 CPU, 2GB RAM, 10 GB storage
150 2 2 (100;13.5) (100;16.63) 100
Operating System CentOS 6.5 - Linux Kernel 2.6
200 2 2 (100;56.4) (100;61.86) 100
SIPProxy Kamailio 3.1.4
Media Server RTPProxy 2.1
Database MySQL TABLE VI. EXPERIMENTAL RESULTS FOR THE ELASTIC VOIP SOLUTION IN
EXPERIMENT 2.
UAC and UAS SIPP 3.4
CPS # VCPU RAM Min CPU % Max CPU % # Completed
TABLE III. ELASTIC VOIP SOLUTION CONFIGURATION 250 3 3 (100;68.6;1.5) (100;70.3;1.5) 100
300 3 3 (100;86.13;1.5) (100;89.33;1.5) 100
Resource Description
350 3 3 (100;95.18;1.5) (100;98.95;1.5) 100
KLB Instance 1 CPU, 1GB RAM, 10 GB storage
400 3 3 (100;100;2.05) (100;100;3.03) 100
KR Instances 1 CPU, 1GB RAM, 10 GB storage
VM Database 1 CPU, 1GB RAM, 10 GB storage
Operating System CentOS 6.5 - Linux Kernel 2.6
Load Balancer Kamailio 3.1.4 B. Experiment 2: Elasticity and Quality of Service
SIPProxy Kamailio 3.1.4 In Experiment 2, heavy load tests were performed exclu-
Media Server RTPProxy 2.1 sively on the elastic VoIP solution in order to demonstrate
Database MySQL
that the proposed solution is able to automatically scale-up
UAC and UAS SIPP 3.4
resources to efficiently support workload spikes. The tests
TABLE IV. EXPERIMENTAL RESULTS FOR THE TRADITIONAL VOIP SOLUTION started with 250 CPS and reached a maximum of 400 CPS
IN EXPERIMENT 1 because this exceeds the double of the capacity supported by
CPS # VCPU RAM Min CPU % Max CPU % # Completed the traditional VoIP solution and it is also sufficient as a
50 3 3 6.39 6.78 100 conceptual test to evaluate the infrastructures dynamic growth
100 3 3 11.42 11.89 100 capacity. In Table VI the obtained results for this dynamic case
150 3 3 15.68 16.3 100 can be seen. It is remarkable that the proposed solution com-
200 3 3 34.96 35.84 85.5 pleted each test with 100% of completed calls, demonstrating
that it can dynamically adjust resources according to workload
To generate and receive calls the same tools were used as demands maintaining a high-quality of service. It can also be
in the traditional VoIP solution case. In Figure 2, the selected observed that increasing KR instances is an adequate approach as
settings for this environment are presented. it allows to serve the demand of calls.
To evaluate the performance (in terms of resource utilization
and quality of service) of both VoIP solutions, stress tests were V. CONCLUSIONS
carried out similar to a benchmark test extracted from [17] that
In this work, an elastic VoIP solution with auto-scaling that
corresponds to an overload tests normally used to measure
increases or decreases according to call demand was proposed.
the performance of VoIP platforms based on SIP. The tests
The solution is presented using open-source tools that have a
consisted in sending a determined amount of transactions per
proven effectiveness including in production environments, such
second (or CPS) during a given time period, evaluating the
as OpenStack, Kamailio, RTPProxy and MySQL. The use of these
CPU and RAM utilization, as well as the percentage of calls
tools helps keeping the solutions initial investment costs
completed by the system.
moderate since no licenses or expensive equipment are required,
A. Experiment 1: Resource Utilization having a quick implementation of the solution with proven tools
In Experiment 1, a comparison between both VoIP solutions and broad support by the open-source community.
is performed in order to evaluate its resource utilization. In It is worth highlighting that additional tools were developed
order to present consistent values, 10 runs of the experiment to aid the implementation of the proposed solution.
were performed and each run lasted 10 minutes. According to experimental results between a traditional and a
Table IV summarizes the average values of the obtained elastic VoIP solution, it can be concluded that dynamic system
results for the traditional VoIP solution. Column CPS represent makes a more efficient use of the resources when there is a low
Call per Second, # VCPU represents the number of CPU or null quantity of calls since it only uses the minimum amount
allocated for this infrastructure, Min CPU % and Man CPU % required of resources in that moment. On the other hand, it can
represents the minimum and maximum CPU utilization. Finally, support great demands of transactions, scaling elastically
# Completed represents the number of calls completed according to the requirements, achieving in this way a high-
successfully. Table V summarizes the average values of the availability and therefore a better quality of service of the VoIP
obtained results for the elastic VoIP solution. system when compared to a traditional solution with static
As can be seen in Tables IV and VI, between 50 and 150 allocation of resources.
CPS both VoIP solutions respond well to the performed tests, Several ideas could complement even more the proposed
considering that both solutions supported 100% of calls. Nev- VoIP solution, such as monitoring quality of service at a higher
ertheless, the traditional VoIP solution required more resources level than CPU (i.e. call quality) for scaling the infrastructure.
in comparison to the elastic VoIP solution. REFERENCES
Reaching 200 CPS, it can be seen that the traditional VoIP
solution supported only 85% of the calls. Consequently, the [1] R. Freeman, " Fundamentals of Telecommunications". John Wiley and
Sons, Inc., 1999.
solution was no longer capable of serving all requests in a

46
[2] J. Petit, D. Gurle, O. Hersent, " IP Telephony: Packet-based
MultimediaCommunications Systems". Addison-Wesley Professional.,
1999.
[3] J. Rosenberg, R. Shockey " The Session Initiation Protocol (SIP): A
KeyComponent for Internet Telephony". Computer Telephony, June 2000.
[4] L. A. Barroso, U. Holzle, " The case for energy-proportional
computing". IEEE computer., 2007.
[5] S. Chavan, R. Mogre, "Resource Provisioning for Elastic Applications
on Hybrid Clouds Enviroment", International Journal of Advanced
Research in Computer Science and Software Engineering, Vol. 3, Issue 8,
pp. 619-622. IJARCSSE, 2013.
[6] N. Janssens, X. An, K. Daenen, C. Forlivesi, "Dynamic Scaling of Call-
Stateful SIP Services in the Cloud", Networking 2012, 11th International
IFIF TC 6 Networking Conference, pp. 175-189. Prague, Czech
Republic: Springer, 2012.
[7] "Openstack Cloud Software", https://www.openstack.org/ (retrieved
2014).
[8] P. Mell, T. Grance, "The NIST Definition of Cloud Computing". Special
Publication (NIST SP) - 800-145, 2011.
[9] "SIP RFC 3261", https://www.ietf.org/rfc/rfc3261.txt (retrieved 2014).
[10] "RTPProxy", https://www.rtpproxy.org/ (retrieved 2014).
[11] P. Bellavista, A. Corradi, L. Foschini, A. Pernafini, "Automated Provi-
sioning of SaaS Applications over IaaS-Based Cloud Systems", ESCOCC
2013, CCIS 393, pp. 94-105. Springer-Verlag Berlin Heidelberg, 2013.
[12] "The Ceilometer Developer Documentation",
https://docs.openstack.org/developer/ceilometer/ (retrieved 2014).
[13] Heat Developer Documentation,
https://docs.openstack.org/developer/heat/(retrieved 2014).
[14] "Kamailio Opensource SIP Proxy", https://www.kamailio.org/
(retrieved2014).
[15] W. Wang, H. Chen, and X. Chen, "An availability-aware virtual machine
placement approach for dynamic scaling of cloud applications". In 9th
IEEE International Conference on Ubiquitous Intelligence and Computing
and 9th International Conference on Autonomic Trusted Computing
(UIC/ATC), 2012.
[16] "SIPP", https://sipp.sourceforge.net/ (retrieved 2014).
[17] Transnexus, "Performance Benchmark Test for OpenSER with RTPProxy",
https://www.transnexus.com/ (retrieved 2014).

47