Kniga Trixbox

Performance Analysis of Asterisk VoIP Server
with Static and Real-Time Database Call

Processing
Butt, Muhammad Faisal Nazir

Master Thesis
Computer Engineering
2006 Nr: E3393
Butt, Muhammad Faisal Nazir Degree Project August 2006
E3393D
DEGREE PROJECT
Computer Engineering
Programme Reg number Extent

COMPUTER ENGINEERING E 3393 D 30 ECTS
Name of student Year-Month-Day
Butt, Muhammad Faisal Nazir 2000-08-21
Supervisor Examiner
Mr. Kari Bjorn Dr. Pascal Rebreyend
Company/Department Supervisor at the
Company/Department
Helsinki Polytechnic Stadia / Cuuma Communications Oy Mr. Kari Bjorn

Title
Performance analysis of Asterisk VoIP Server with Static and Real-time Database Call Processing
Keywords
VoIP, Asterisk, SIP, Real Time Database model, Resources, Parameters, VoIP traffic, Performance
analysis
Dalarna University 2 Tel: 023778800

Roda vagen 3 Fax:023-778050
S-781 88 Borlange http://www.du.se
E3393D
Abstract
The main objective of this Degree project was to analyze performance of VoIP based
Private Branch Exchange (PBX) “Asterisk”for business purposes. The performance
analysis is useful for predicting the baseline performance measurement of Asterisk
in static and real-time call processing on different platforms, with different speed
CPU. Call success rate and CPU utilization in static and real-time (database) call
processing are example of performance measures.
To reach the goals of defined system, different operating system and hardware
parameters were used. Firstly, two PC-based PBX with connected IP phones on
LAN were setup and configured for static and real-time call processing on different
speed Linux Servers to fulfill the requirement of a complete enterprise VoIP system.
After that performance was analyzed by generating the burst of variable calls load
(calls/sec) at static and real-time Asterisk’
s. The SIP traffic generator software was
used to generate and receive the burst of SIP calls. Windows analyzing tool based
on the performance parameters call success rate, CPU and memory utilization, is
used to analyze the results.
Based on the analysis results, the conclusion was drawn that Asterisk is platform
dependent for call success rate in static and real-time call processing. The
performance is analyzed for 350 MHz and 2.4 GHz Asterisk servers for static and
real-time call processing and results are concluded. This performance analysis is
very useful for small office system, to investigate the limited number of calls/sec with
low cost hardware.

E3393D
PREFACE
The report presents the master thesis, concluding my studies to Master in Computer
Engineering majors in Telecommunications at Dalarna University, Faculty of
Computer and Electrical Engineering. The aim of this thesis work was to gain
experience in the independent research work, and achieve deeper understanding of
a key subject area. The workload is about 30 ECTS.
This thesis has been conducted in the Cuuma Communications Oy at Ruoholahti

High Tech Center, Finland. I would like to express my sincere appreciation to Mr.
Kari Bjorn who gave me chance to work in very healthy research environment.
My supervisor in the project has been Mr. Kari Bjorn; I would like to thank for his
valuable help and guiding me through this thesis. I also like to thank Mr. Anh Dung
Le (Cuuma Communications) for his smooth and independent attitude to instruct me
through the contents of this master thesis.
I would like to thank the entire faculty of Dalarna University and Helsinki Polytechnic
Stadia, especially professor Mark Dougherty, program coordinators Dr. Pascal
Rebreyend and Hasan Fleyeh who gave me chance to pursue my Master studies in
Sweden.
Additionally, I want to thank my family and friends for patience and support during
this thesis work.
Helsinki 21 August 2006
Butt, Muhammad Faisal nazir

E3393D
Table of Contents
1 Introduction ...............................................................................................................................7
1.1 Background...........................................................................................................................8
1.3 Limitations............................................................................................................................9
1.4 Questions For Investigation.................................................................................................9
1.5 Structure of Thesis .............................................................................................................10
2 Problem Formulation .............................................................................................................11
3 System Overview .....................................................................................................................12
3.1 Circuit Switched Network .................................................................................................14
3.2 Packet Switched Network..................................................................................................14
3.3 Voice over IP......................................................................................................................15
3.3.1 User Terminals............................................................................................................15
3.3.2 Codecs .........................................................................................................................15
3.3.3 Call Processing Server / IP PBX................................................................................16
3.3.4 Media / VoIP Gateway ...............................................................................................17
3.2.5 IP Network / Gatekeeper ............................................................................................18
4 Session Initiation Protocol (SIP) ...........................................................................................18
4.1 SIP Distributed Architecture .............................................................................................19
4.1.1 User Agents.................................................................................................................20
4.1.2 Proxy Server................................................................................................................20
4.1.3 Registrar Server ..........................................................................................................22
4.1.4 Location Server...........................................................................................................22
4.1.5 Redirect Server............................................................................................................23
4.2 General SIP Transactions Model ......................................................................................24
4.3 SIP Messages......................................................................................................................25
4.3.1 SIP Requests ...............................................................................................................25
4.3.2 SIP Responses.............................................................................................................27
4.4 Real-time Transport Protocol (RTP).................................................................................28
4.4.1 RTP Components........................................................................................................28

E3393D
5 Performance Evaluation and Analysis.................................................................................30

5.1 Evaluation at Life Cycle Phases........................................................................................31
5.2 Evaluation Methods ...........................................................................................................32
5.3 Performance Evaluation Techniques ................................................................................33
5.3.1 Performance by Measurement ...................................................................................34
5.3.2 Performance by Modeling..........................................................................................34
6 Asterisk Private Branch Exchange (PBX)...........................................................................36
6.1 Asterisk Detailed Architecture..........................................................................................36
6.2 Introduction to Dial Plans..................................................................................................39
6.2.1 Fundamentals of Dial Plans .......................................................................................39
6.3 Static and Real-time Dial Plans.........................................................................................41
6.4 Asterisk Files Organization and Configuration................................................................42
7 Experimental Setup and Analysis.........................................................................................45
7.1 Experimental Setup Overview ..........................................................................................45
7.2 Software used in Experiments...........................................................................................46
7.2.1 Call Generation and Emulation (WINSIP) ...............................................................46
7.2.2 Server Performance Measurement Tool....................................................................47
7.3 Experimental Setup Details ...............................................................................................48
7.3.1 Test Scenario 1............................................................................................................49
7.3.2 Test Scenario 2............................................................................................................51
7.3.3 Test Scenarios 3 and 4................................................................................................53
8.0 Results Analysis....................................................................................................................53
8.1 Results of Test Scenario 1 .................................................................................................53
8.2 Results of Test Scenario 2 .................................................................................................55
8.3 Results of Test Scenario 3 and 4.......................................................................................57
8.4 Results Analysis .................................................................................................................59
9 CONCLUSION AND FUTURE WORK .............................................................................61
REFERENCES ...........................................................................................................................62
APPENDICES.............................................................................................................................64

E3393D
1 Introduction
Voice-over-IP is a technological buzz in the world of telecommunications that has
the potential to completely rework the traditional telephony. VoIP have been
developing very rapidly in the last decade, the main idea behind this revolution was
to achieve the increased functionality, scalability and low cost telephony.
In current-day VoIP networks, the main quest is to achieve the better performance
and quick response time. The bottleneck in shifted from physical link limitation (high-
speed and high bandwidth) to the performance of the processing elements. These
processing elements ca be hardware components, functional software or protocols.
To evaluate the performance of a system different evaluation techniques need to be
considered. Performance evaluations are activities undertaken to characterize the
operations of the system. The study of performance evaluation is applied to both
existing system and system to be designed. These systems are evaluated for the
purpose of assessing and improving their performance.
This thesis study is concerned with performance evaluation of the VoIP server
“Asterisk”using different specifications hardware to analyze the upper call limit and
CPU utilization in static and real-time call processing. The performance analysis is
useful for predicting the performance of the Asterisk for small business, to help in
designing a VoIP network with limited number of resources. Asterisk is a complete
PC-based Private Branch Exchange (PBX) that provides all the functionality and
features of a normal PBX. It is the middle-ware that connects any telephone line,
VoIP interface or telephone circuit to any other interface or service including PSTN
through Asterisk applications.
In this project work the Asterisk performance with static and real-time (database) dial
plans are under investigation. In static dial plans the entire configuration is saved in
the file system, and Asterisk services need to reload when new changes take effect,
while in real-time configuration there is no need to reload Asterisk services when the

E3393D
configuration is changed, In real-time system all the dial plans are saved and
retrieved from a database. The performance of the host CPU and memory utilization
is also investigated for server health.
1.1 Background
This degree project is the requirement for the award of degree in International
Master of Science in Computer Engineering, Hogskolan Dalarna, Sweden. This
project work has been accomplished as the part of ongoing research “SER”(SIP
Express Router) in the Cuuma Communications Oy in Finland. The project is lead by
the research department of Helsinki Polytechnic Stadia with the partner company
Cuuma Communications Oy, and carried out in the premises of High Tech Center
(HTC), Finland.
1.2 Objective
The main objective of this project work is design and analysis of Asterisk VoIP
server, the thesis requires the performance measurement for real-time aspects of
the applications involved. Based on the analysis results, the performance is
measured for the call quantitative aspects of Asterisk for small business area. This
performance analysis is helpful for designing and evaluating the performance of
Asterisk VoIP server for real-time business call processing.
The tasks of the project was to,
• Setup and configure two Linux based Asterisk server with connected IP
phones on LAN.
• Make the call establishment and record routing possible between different
Asterisks and IP phones.
• Configure the Asterisk for static and real-time (Database) call processing.

E3393D
• Measure the baseline performance of static and real-time Asterisk on

different platforms, by generating variable call load (calls/sec).
• Analyze the results and make the performance conclusion for business
purpose.
1.3 Limitations
This project work is limited to the performance of the 350 MHz and 2.4 GHz Asterisk
VoIP servers. To analyze the performance of the systems many hardware and
software parameters were need to be considered. It was impossible in this project
work to implement all the parameters; due to lack of resources, hardware and
software parameters are few. The most crucial resources in this project work were IP
telephones to generate and receive SIP calls. SIP call generator was used to
generate and receive the SIP calls, but that software was also for the limited trial
period of time. Due to these limited resources, analysis is restricted to the 350 MHz
and 2.4 GHz Asterisks.
1.4 Questions For Investigation

In this project work, static and real-time approaches are under investigation to find
out the best call serve rate of Asterisk VoIP servers. Some questions arise during
this investigation, such as:
• How many simultaneous calls a single Asterisk can handle as a function of

CPU speed.
• How Asterisk static and real-time dial plans effects the CPU speed.
• How many calls processed by static and real-time (Database) configuration.

E3393D
• How big/fast the machine required for serving need.

.
In this project work, the investigation focuses on the comparison of static and real-
time (database) configuration of Asterisk call processing to find out the upper call
limit and CPU utilization. The same number of burst calls was generated on both
machines and resulted success rate were examined by comparison.
1.5 Structure of Thesis

This section presents the whole overview of the thesis. The thesis is organized into
eight main sections as follows: In Section 2 the problem formulation is explained,
this section presents the whole idea behind the project work encountered the
problems and methods to solve these problems. Section 3 gives the strong
background overview of the system with comparison of circuit switched and packet
switched, VoIP components and their detail is also discussed in this section. SIP is
the commonly used protocol for Asterisk; Session Initiation protocol (SIP) is
explained in the fourth section of the thesis. This section describes the main aspects
of the SIP, the definition of the SIP network distributed architecture and explain the
function of each element. The following part discusses the SIP message, requests
and transaction models. The SIP messages are about SIP message structure and
types. The transaction models contain many operations based on different types of
SIP messages. Before starting the performance evaluation of Asterisk, the basics of
performance evaluation methods and techniques are also explained in the fifth
section, this section presents the methodology used behind the performance
evaluation of a system. In the Sixth section complete definition of Asterisk PBX is
discussed, the definition of core architecture, components of the Asterisk with
channel and interfaces are explained. The following part also discuses the
Fundamental of dial plans, static and real-time dial plans used in experimental
analysis. Section seven presents the overview of the experimental setup and test
scenario. In this section, experimental detail, software used for testing, Lab setup

E3393D
and methods used are discussed. Result analysis is made based on the extreme
tested raw statistics, and conclusion is drawn based on analysis in the last section of
the thesis.
2 Problem Formulation
In current era, IP telephony offers great promises to simplify business networks due
to its flexible and unique architecture. The increasing popularity and number of users
in VoIP network are effecting the performance of the processing elements. These
processing elements can be hardware components, functional software or protocols.
The performance issues arise in the form of call failure, jitter, delay or latency etc.
This thesis study involves the complete design of VoIP network,

Asterisk compatibility and interoperability testing with other Asterisks and connected
IP phones on a LAN. The main objective of the project was to evaluate the
performance of IP based Private Branch Exchange (PBX) “Asterisk”, specifically to
measure the upper call limit and CPU utilization of single Asterisk for static and real-
time dial plans. The performance is measured at various speeds of Asterisk servers,
by conducting different experiments.
The experiments were conducted for the interest of Cuuma Communications Oy in

the question of investigation for small business “how many simultaneous calls can a
single chassis handle?”No one knows the exact call serving capacity, even estimate
of how many users a typical Asterisk box can support. For this question, Asterisk
static and real-time performance is examined at two different speed Linux servers,
by generating the variable call load (calls/sec) to measure the performance of single
Asterisk for Busy Hours Call Completions (BHCC), and the conclusion is drawn
based on resulting parameters such as, call success rate and CPU utilization.
To evaluate the performance of the Asterisk, many hardware and software

parameters were needed. The most crucial parameters in this investigation were the

E3393D
number of IP phones. It was impossible to connect 500 or more IP phones on LAN.

For this purpose, SIP call generator software was used to generate and receive SIP
calls; it performs like logical phones. The raw statistics are also collected through
this software. CPU and memory utilization is another big issue that has a significant
influence on call processing and accessing dial plans in Asterisk. To analyze the
Asterisk server health such as CPU and memory utilization, third party tool,
Application Manager [16] was used, described in chapter 7. The goal of the project is
achieved by analyzing the performance of static and real-time Asterisk for two
different speed machines, to find out the upper call limit and CPU utilization.
3 System Overview
In data communication networks, many transactions are based on client/server
model of computing. In client server architecture, client machine make a request for
services to server machine, which performs these services and return the results,
Web server, Email server and Database server are the example of client/server
architecture. In addition to voice services on IP network, IP PBX was introduced to
provide these services in innovative way. IP PBX server is PC-based software,
which typically serves as core IP telephony server. It performs all the functionality
like a traditional telephony PBX does. It is the middle-ware that connects IP
telephony to other telephony networks. [1]
In this project work, the performance of IP PBX “Asterisk”is analyzed to find out the
upper calls success limit and CPU utilization for static and real-time dial plans. The
architecture of experimental setup consist of two Asterisk servers with speed of 350
MHz and 2.4 GHz shown in figure 3-1; three fast computers are being used to
evaluate the performance of a single Asterisk for static and real time dial plans.
Computer A with the CPU speed of 2.4 GHz was used as SIP Call generator and
traffic observer, which generates the required number of variable calls (calls/sec) at
the same time to the Asterisk server and monitors the call processing as well.

E3393D
Computer B with the same processor speed of 2.4 GHz receives and answers the
routed calls from Asterisk as actual IP phones serves. To observe the server health
(CPU, memory utilization) and availability, Computer C performs operations at
threshold level; Linux performance analyzer is installed on 2.4 GHz machine and
connected to Asterisk server through secure SSL connection.
`
Asterisk Server1 Asterisk Server 2 Server performance Analyzer
(Computer C)
` `
Switch
SIP call generator (Computer A) SIP calls receiver (Computer B)
WLAN /
INTERNET
IP Phone
IP Telephone Provider
POTS
Analog Phone
Fig 3-1, Proposed System Overview
To understand the functionality of the Asterisk, it is necessary to be aware of the

background of circuit switching, packet switching, protocols and interoperability of
different components with Asterisk, described in the next section.

E3393D
3.1 Circuit Switched Network

In telecommunications networks, Circuit Switched is one that provides a dedicated
circuit or channel before communication occurs between end users (nodes). Circuit
switched network is also known as Public Switched Telephone Network (PSTN), the
services provided by the PSTN are known as POTS. In Plain Old Telephone
Services (POTS), everyone takes for granted uses circuit-switched connections,
which means when somebody makes a phone call, a single dedicated channel
assigned to caller and callee conversation, which remains occupied during
conversation. Each dedicated circuit may remain active between two communication
nodes during conversation, and cannot be used by other callers until the channel is
released. [1] [6]
Circuit Switched Network uses five main components; Voice encoding, PSTN
Switches, Private Branch Exchange, Signalling and Telephones. Every component
performs its operations to provide the fast and reliable calls on PSTN. A typical
dedicated circuit through the PSTN, from physical connection to logical connection
uses many switches. At the conversation, encoded voice passed along the
dedicated circuit through these switches.
3.2 Packet Switched Network

In Packet-switched network, multiple users share the single data network for
communication. The communication is established by sending the segments of voice
or data packets on the same data network. Each packet contains addressing
information that specifies the source and destination computer. The packets in a
single transmission can take different paths from end-to-end, across the data
network.
The structure of data packets is as, each packet consists of header section and their
payload – are snippets of voice conversation. To transmit Voice over IP network, the

E3393D
voice is need to be converted from analog to digital, cut into packets, sent across the
network in packet format, resembled and converted back from digital to analog.
Encoders and decoders at either end do the conversation from analog to digital and
back. Different components are involved to transmit the Voice over IP network,
described in the next section. [1] [6]
3.3 Voice over IP

To Place the voice calls on the packet switched network, VoIP system uses number
of different components; most of them perform the similar functionality as the
traditional telephony, PSTN. Additionally, VoIP network contains gateway
component that enables VoIP calls sent to the PSTN and vice versa. The important
VoIP components are described below in detail. [1] [6]
3.3.1 User Terminals

User terminals are known as endpoint communication devices, such as VoIP phones
and desktop based devices. It could be software based soft phone or hardware
based handset. An IP phone provides number of functions; one of them is
human/machine interface, and has a codec for analog to digital conversion to
represent the digital speech.
3.3.2 Codecs
A Codec simply known as the coder / decoder or in more general words compressor
/ decompressor, is a hardware or software that samples analog sound, converts it to
digital bits, and output it at a predetermined data rate. Each codec use different data
rate, G.711u and G.711a works at the nominal data rate of 64kbps with
packetization delay of 1ms; G.726 performs compression at 32 kbps and G.729
codes the voice segment at 8 kbps data rate with packetization delay of 25 ms. The
packetization delay refers to a delay time of codec to convert from analog to digital
and back. Some codecs performs compression to save bandwidth. There are

E3393D
dozens of codecs available, each with its own characteristics. The most common
codecs used in VoIP are G.711u, G.711a, G.726-32, G.729, G.723.1 MPMLQ and
G.723.1 ACELP. [1]
In this thesis work, G.711 codec was used to encode the VoIP calls. The G.711
codec is generally known as the Pulse Code Modulation (PCM), the signalling
functionality of this codec is described below,
• It uses the frequency range of 4kHz to capture the human voice conversation.
• To capture the proper degree of resolution, the voice information is sampled

at double the frequency range, or 8000 times per second. Thus PCM grabs
the chunk of data every 0.125 ms i.e. (1 second / 8000+0.000125 seconds)
• Each sample occupies 8 bits of data, so the overall bandwidth required is

(8000 * 8), or 64000 kbps. [1, Page 85]
3.3.3 Call Processing Server / IP PBX

The most important component in the VoIP communication is Call processing Server
/ IP PBX. It is known as the heart of VoIP system, IP PBX typically serves as the
core IP telephony server by adding the voice data to IP network. In the Public Switch
Telephone Network (PSTN), the traditional PBX is a closed-box system that
provides all the necessary voice functions and features, but usually in a proprietary
manner. In VoIP, the IP PBX is the PC-based software that runs on different
operating systems, such as Linux, BSD and Windows. It can be managed by the
vendors Application Programming Interface (APIs) and through the standard APIs
provided by the operating system. [1][7]
An IP PBX provides all the functions and features similar to those that a traditional
PBX provides. It manages call control and signalling traffic of the VoIP network, the

E3393D
basic function of signalling traffic is to establish and terminate a call. The signalling
traffic also provides control over the call session. There are different protocols
available to serve as the VoIP signalling protocol, SIP and H.323 being the two
major choices.
3.3.4 Media / VoIP Gateway

Media Gateway performs two main functions. It converts the format of the voice from
the world of traditional telephony to VoIP (analog-to-digital), which is called
transcoding, and also converts the signaling for call setup part. There are several
kinds of media gateways available, described below, [1]
Residential gateways provide traditional analog interface to the VoIP network.

Examples of residential gateways include cable modem, xDSL modem and analog-
to-digital adaptor.
Trunk gateways provide the interface between the traditional telephone network
and VoIP network.
Access media gateways provide a traditional analog or digital private branch

exchange interface to a VoIP network.

E3393D
3.2.5 IP Network / Gatekeeper

Gatekeeper is the set of functions that are responsible to control group of terminals.
Gatekeeper performs number of signalling functions to work with VoIP devices; most
important is RAS (registration, admission and status). Registration takes care of
giving each of IP phones an IP address and possibly address translation. Admission
is whether somebody is allowed to make a phone call or not.
4 Session Initiation Protocol (SIP)

To place a call on the data network, VoIP involves two types of protocol; call setup
protocols and voice streaming protocols. Call setup protocols are available to serve
as the VoIP signalling protocol, SIP, H.323 and IAX are most common choices.
Session Initiation Protocol (SIP) is the most common signalling protocol used by the
Asterisk VoIP server. In this section, the focus is on the SIP call signalling and
operations.
Session initiation protocol is an application layer signaling protocol, which has been
developed and designed within the IETF [1]. It is used to define initiation,
modification and termination of multimedia communication sessions between end
users. Here, session is considered to be communication states kept between
senders and receivers during the communication. Examples of communication
sessions are Internet telephone calls, distribution of multimedia etc. In the next
section, the structural, functional and characteristics features of SIP are discussed in
detail.

E3393D
4.1 SIP Distributed Architecture

SIP is divided into five logical components, User Agents, Proxy Server, Location
Server, Registrar and Redirect Server, as shown in Figure 4-1.
Location Server Registrar Server Redirect Server
PSTN
`
Proxy Server Proxy Server
User Agent
Gateway
Figure 4-1, SIP Distributed Architecture
These all elements work together on one computer to perform specific task.
Installation of these elements on the same machine increases the speed and
processing between the network elements. The above figure 4-1 describes SIP
components internal working on single machine. These components are described
in the next section in detail. [10][11][12]

E3393D
4.1.1 User Agents

Internet end points that use SIP to find each other and to negotiate a session
characteristics are called User Agents [10]. User Agent is an application that can
initiate, receive and terminate calls. User agents can reside on the user computer in
the form of an application, but they can be cellular phones, PSTN gateways, PDA’
S
and IVR (Interactive Voice Response) systems and so on. User agents referred to
two logical entities known as UAS (user agent server) and UAC (user agent client).
UAC is an entity that makes a call or request to callee. UAS receives a call or
request from caller and send response.
Request
Response
UAC UAS
SESSION
Figure 4-2, Simplest communication between UAC and UAS
In Figure 4-2, general model between UAC and UAS is described. UAC sends
request to UAS, UAS response that request and the session established between
them.
4.1.2 Proxy Server

Proxy server is an intermediate program that receives SIP requests from user
agents and forward request on requestor behalf [11]. Proxy server acts as an
intermediate program and requests are serviced internally or passing them on,
possibly after translation to other servers. SIP proxy maps email address to the PBX

E3393D
extensions for each inbound call and forward the call to related server of gateway.
[11]
There are two types of proxy server, Stateless and Stateful proxy servers.
In stateless servers, simple messages are straightly forwarded. The forward

messages are independent of each other and do not take care of transactions.
Stateless servers can be used as load balancer, message translator and router.
Stateful servers are more complex as compared to the stateless servers. These
servers keep the state alive until the transaction finish. Stateful servers perform
some important features like forking (searching of one request at multiple
destinations).
Session Established
Destination 1
STATEFUL
ANSWER UAC
INVITE INVITE UAS

UAC PROXY
SERVER
Destination 2
UAS (FORKING) DECLINE

UAC
INVITE
UAS
Figure 4-3, Communication example of Stateful Proxy Server
Figure 4-3 illustrates the stateful proxy server behavior. UAC requests for UAS and
Proxy server forward the request to multiple destinations. The current destination of
UAS answers the invitation; remaining sends the decline message.

E3393D
4.1.3 Registrar Server

Registrar server is a logical SIP entity that accepts the registration requests from
senders extract registration information about current location (IP address, port and
username) and store that information into location database. At the completion of
registration process, Registrar Server sends the ACK 200 message to the requestor,
shown in Figure 4-4. Registrar is very important entity that helps in storing current
information in location database, which further use for forking by proxy or redirect
server. [1][10][11]
UA Registrar Location
Location Database
Register
200 OK
`
Registrar Server
User Agent
Figure 4-4, Communication example of Registrar Server
4.1.4 Location Server

A location server is a SIP entity used by a proxy and redirect server to obtain the
information about the called party possible location, shown in Figure 4-5. Location
server stores the current location of the users by registration process. The location
server generally contains information that allows a proxy to input a URI and receive
a set of zero or more URI’
s that tell the proxy where to send the request. [1][11]

E3393D
P ro x y S e rv e r L o c a tio n D a ta b a s e R e d ire c t S e rv e r
F ig u r e 4 - 5 , L o c a t io n S e r v e r
4.1.5 Redirect Server

A Redirect server is a user agent server that accepts and receive SIP request, map
the addresses into zero and more new addresses and return these addresses to the
client. [1] Redirect server checks the request from the location database and creates
the list of current location of the user and send back the request to the originator
within a 3xx response (these responses will discuss later in section 4.3.2 in detail).
The user receives the list of current destinations and send request directly to
required destination, shown in Figure 4-6. Unlike, the proxy server the redirect
server does not initiates SIP request and not accept or terminate calls like user
agent server. [1][11]
R e d ir e c t S e r v e r
il y
1
ar
TE
30 por
VI
m
2
IN
te
ed
ov
M
IN V IT E 2
` `
U ser Agent 1 U ser A gent 2
F ig u r e 4 - 6 , R e d ir e c t S e r v e r o p e r a ti o n a l b e h a v io r

E3393D
4.2 General SIP Transactions Model
A general SIP transaction model consists of sequence of SIP messages (requests

and responses) between SIP network elements [10]; shown in figure 4-7 which
describes the SIP calls setup and teardown process.
` `
User Agent Proxy Server Location / R edirect Server Proxy Server User Agent
INVITE INVITE
302
M oved Tem porarily
ACK
INVITE
INVITE
302
M oved Tem porarily
ACK
INVITE
180 Ringing 180 R inging 180 Ringing
200 OK 200 OK 200 OK
ACK ACK ACK
R TPMM
RTP E DIAPATH
EDIA PA TH
BYE BYE BYE
200 OK 20 0 OK 200 OK
Figure 4-7, SIP general transaction model

E3393D
In Above Figure 4-7, Sequence of requests and their responses are used in number
of steps to complete the call process. The detail of these requests and responses
are described in next section to understand their purpose of working.
4.3 SIP Messages

SIP messages are used to make communication possible between SIP network
elements. SIP is text-based protocol with syntax similar to HTTP. There are two
types of SIP messages, either Request from client to server or Response from
server to client. The format of both message types (Request or Response) consists
of a start line, one or more header field, an empty line shows end of header field and
optional message body such as SDP media description. [10][11][12]
Generic- message = start-line* Message-header

CRLF
[Message-body]
Start-line = Request-Line / Status-Line
Note: CRLF (carriage-return line-feed sequence) is used to terminate the start-line,

message-header line and empty line. [11]
4.3.1 SIP Requests
SIP requests are the messages from client to server, and distinguished by having a
Request-Line for a start-line. A Request-Line contains a method name, a Request-
URI, and the protocol version separated by single space (SP) character. The format
of the Request-Line is as
Request-Line = Method SP Request-URI SP SIP-Version CRLF

E3393D
Method is an important entity in the request line and used to decide the function of
request, six types of methods are defined: REGISTER, INVITE, ACK, CANCEL,
BYE, OPTIONS. [10][11]
Register request is used to register user agents and allow registrar to save the user
information (IP address, port) in the location database.
Invite is request to initiate the call by inviting the user to participate in the session.
The message contains a description of the session, using session description
protocol (SDP), and type of the media that is to be used for the session.
ACK Confirms the final response of the Invite request, that user is available for
communication.
Cancel is used to cancel not yet fully established session. It is used when caller
wants to refuse the call invitation from Callee.
Bye message is used to terminate the specified communication session. All the
participating communicating parties can send BYE message to end the call. BYE
method only terminates the call and dialog associated with it.
Option is method used for querying the capabilities of SIP server or client. Option
method allows a UA to query another UA or a proxy server as to its capabilities.
This allow client to discover information about supported methods, content types,
extensions, codec etc. without “ringing”the other party.

E3393D
4.3.2 SIP Responses

Every request needs a response, when a user agent receives a request it replies the
response. Response method are similar to request, except to the first line. First line
of the response contains protocol version (SIP/2.0), reply code, and reason phrase.
The reply code is integer number from 100 to 699 and indicates type of response.
There are 6 classes of responses:
1xx: These responses are known as provisional or informational responses. These

indicates the request is received and some unspecified actions are taken on behalf
of this call, the example of these responses are 100 Trying, 180 Ringing, 181 call is
being forwarded etc.
2xx: This response indicates that call is processed successfully and accepted.
When caller sends the call request and callee picks up the phone, 200 OK
messages is sent back by the indication that call is successful.
3xx: 3xx or redirect responses, gives the new location information of the callee.
4xx: These are the bad syntax or negative responses at the sender side. These
responses indicate that there is problem at the sender end and can not processed at
server side.
5xx: Server Failure Responses, which means that request is valid but server is
unable to solve the request.
6xx: Global Failure responses, Indicates that request cannot process at any server.
This is usually the decline response from user agent when it does not want to
participate in the session.

E3393D
4.4 Real-time Transport Protocol (RTP)
RTP is the most commonly used voice streaming protocol in Internet telephony
applications. Real-time transport protocol is used to transmit multimedia data such
as audio, video or simulation data, over multicast or unicast network, after call setup.
RTP does not in itself guarantee real-time delivering of multimedia data. The Control
protocol (RTCP) is used to monitor the data delivery, control and identification
functionality in a manner scalable to large multicast networks. RTP works with other
protocols to make call possible. Typically RTP runs on top of the UDP protocol,
although specification is general to support other transport protocols. [1]
4.4.1 RTP Components

RTP consists of four main fields; the detail of these fields is described below:
[1,page 22]
RTP Payload type indicates the specific media encoding, which codec to use. The
codec conveys the type of the data (such as voice, audio or video) and how it is
encoded. It can be changed if it has to adapt the variation in bandwidth, frame
indication, which arks the beginning and end of each frame.
Sequence number helps the receiving sides reassemble the data and detect lost,
out-of-order and duplicate packets (datagram’
s).
Time Stamp, It is used to reconstruct the timing of the original audio and video. It
also helps the receiving side determine variations in packet arrival times, known as
jitter. It is the time stamp that brings real value to RTP. At receiving side each packet
is compares with time stamp to make RTP transmission possible.
Source ID, It is used to distinguish among multiple, incoming streams by the

software at the receiving side.

E3393D
R TP D atagram R TP D atagram R TP D atagra m
IP H eader U D P H eader R TP H eader R TP Payload (the D ata)

20 bytes 8 bytes 12 bytes N bytes
CSRC Payload Sequen ce Tim e So urce

Version Padding E xtension M arker
C ount Type N um be r S tam p Id entifier
4bits 1 bit 1 bit 1 bit
1 bit 7 bits 2 bytes 4 bytes 4 bytes
F igure 4-8, H eader used for R T P follow s th e U D P H eader in e ach D atagram [1 ]
RTP is a connectionless protocol and its datagram encapsulates inside the UDP
datagram to travel through the network. In this project work, RTP is used as voice
streaming protocol to send real-time traffic.

E3393D
5 Performance Evaluation and Analysis

In this chapter, the performance evaluation objective and techniques are discussed.
Performance Evaluations are activities undertaken to characterize the operations of
the system, shown in Fig 5-1. The main reason of performance evaluation is to
provide expected performance indication, configuration and tuning of the existing
system elements and services, and to help in design and development of the new
system. To evaluate the performance of any system, three parameters need to be
considered; measurement, analysis and modeling. Measurement is concerned with
the continuous or as-needed monitoring of the existing system, while analysis adds
the comparison of the measured parameters to the applications of controlled stimuli
[2]. Modeling is the useful study for the new system to be designed.
P r o b le m - I d e n t if ic a t io n a n d
R e q u ir e m e n ts A n a ly s is
C h a r a c te r iz a tio n
(W o r k lo a d /S y s te m P a r a m e te r s )
E x p e r im e n t s M o d e lin g
(M o n it o r in g o f R e a l S y s te m s ) (W o r k lo a d /S y s te m B e h a v io r )
A n a ly sis o f A n a ly sis b y M a th e m a tic a l

M e a s u r e d V a lu e s M e th o d s o r S im u la t io n
V a lid a t io n V a lid a tio n
S y n th e s is o f O p tim iz e d S t r u c t u r e s
S e n s itiv ity A n a ly s is
F ig u r e 5 -1 , O v e r v ie w o f P e r fo r m a n c e E v a lu a tio n M e th o d o lo g y [

E3393D
5.1 Evaluation at Life Cycle Phases

Before, evaluating the performance of any system it is necessary to assure the
design of system accomplished correctly according to life cycle phases. Several
methodologies exist for verifying the compliance to specifications.
“However, since system consist of hardware and software, it is also common to fully
design, implement and functionally test them before an attempt is made to determine
their performance characteristics”(E Brinksma). [3]
The first step towards the correctness of the system is conformance testing. A
system being designed or to be designed must satisfy the predetermined
specification of the system. Conformance testing ensures the performance of the
system in accordance with the specification on which it was build. These
specifications varies from system to system depends on the operations, system
elements and services performance as expected.
The next logical step after conformance testing is interoperability. A system can be
defined as the set of components working together to perform specific tasks. The
performance of any system is affected by the performance of its component’
s and
the way these components are connected together. For example, if there are two
systems A and B satisfying the specification X, Interoperability evaluates the extent
to which system A and B can work with one another.
After the successfully implementation of conformance and Interoperability testing of

the system, it would expected that system has to perform its set of functions and
tasks correctly i.e. giving the correct results of the given input, Figure 5-2 is
presenting the overview of the system life cycle.
A correct design may not imply one that performs blazingly fast or very cost
effective. Several other factors are involved in the performance of any system. Cost
and speed are the parameters under investigation.

E3393D
This may be due to other conditions – for example, we may need to trade off
performance or perfect correctness to save cost per unit. (E Brinksma) [3]
Figure 5-2, System Life Cycle Phases [3]
5.2 Evaluation Methods
The most important driving factor in designing and development of a system are its
efficient performance and functionality in cost effective manner. To improve the
functionality and efficiency of the system, two evaluation classes are defined
comparative evaluation and analytic evaluation.
The analytic evaluation is very effective in some cases, where the system is
examined with respect to various system parameters and system workload, such as
building an analytical model in which different system parameters are related by
equations.
In comparative evaluation, the system performance is evaluated as compared to the

other system under study. Comparative evaluation is useful in some cases but in

E3393D
most of the time the comparison is not reliable, because the cost, performance and
correctness of every system is different. [4][5]
5.3 Performance Evaluation Techniques

Performance evaluation is one of the fundamental factors to investigate and optimize
the real-time behavior of individual components of the system. Several evaluation
techniques are used to evaluate the performance of real-system behavior; most
commonly used are measurement and modeling.
“Performance evaluation includes the measurement and modeling of real-system

behavior, the definition and determination of characteristic performance measures,
and the development of design rules, which guarantee an adequate quality of
service”(E, Brinksma). [3]
Direct measurement is the most commonly used and flexible technique for the
investigation of the system. In direct measurement set of predefined parameters are
used to evaluate the performance of the system. It could be as needed or
continuous monitoring of the system via dedicated monitoring tool (software or
hardware) and analyzed by comparison of the system; Speed and cost are the
example of parameters measures.
The direct measurement always concerned with the correctness of the system
according to life cycle phases. It is very accurate and flexible approach to evaluate
the performance of an existing system. While, in some situation where system is not
fully designed or the to be designed, the modeling plays an important role in the
development and evaluation of the system. In the next section, these two
techniques are discussed in detail.

E3393D
5.3.1 Performance by Measurement

Measurement is a technique used to evaluate the performance of the system in
accurate manner. In simple words, measurement is an observation that is collected
and recorded from the real-system outcome to accomplish pre-established research
goals. Performance Evaluation predicts whether a system has achieved its goals,
described as measurable performance standards.
To obtain a good measurement results different tools and techniques are used. In
measurement, the actual behavior of the system is investigated by applying the
theory and tools, not a conceptual difference in either theory or tools. The need of
computer system measurement can be divided into three categories depending on
the reason for which one does the measurements: diagnostic measurement,
performance measurement and analytic measurement.
Diagnostic measurement secures correct operation while a computer system is in

use and to restart correct operations in case of system failure. Performance
evaluation ensures efficient operations fast response of computer system under
dynamically changing demands. Analytic measurement in other hand develops an
understanding of the processing requirements and their impacts on the system
behavior and performance. [3][4][5]
5.3.2 Performance by Modeling

Modeling is the technique used to define system and its problem in a concise
fashion. It is the study to evaluate the proposed solution for the system to be
designed. A model can build for the whole system or part of it and can be validated
by comparing the existing system or features of the system to be designed. Models
are helpful in predicting and planning for future enhancement and development of
the system.

E3393D
“Descriptions of system models are typically developed based on the theoretical

laws and principles. They can be physical models (scaled replicas), mathematical
equations or graphical representation”(Paul Fourtier). [4]
Model is considered to be accurate, if it gives the concise and close results to the
results taken from the direct measurement on the existing real system. The model
results are based on the performance measures parameters, these parameters may
vary from system to system. A model can be consider a good model, if physical laws
that can be used to describe a system are discussed in detail, secondly the Pictorial
representation can be made to provide the better understanding of the model, the
last but not least is system inputs, element, and output are of manageable
magnitude.
R EA L SY STEM
Ab
st
P r r a c ti
o ce on
ss
M o d e ls
F ig u r e 5 - 3 , M o d e lin g o f S y s te m [ 4 ]
In this thesis study the performance of Asterisk is analyzed by using the

measurement techniques as described above. The measurement parameters used
in performance evaluation of Asterisk is upper call limit as function of CPU utilization.

E3393D
6 Asterisk Private Branch Exchange (PBX)

Asterisk is a Linux based open source software designed by the Mark Spencer [7],
that performs all the features and functions like Private Branch Exchange (PBX) and
Interactive Voice Response (IVR) system. Asterisk is hardware independent API,
and is designed to replace traditional PBX, which means it performs all the features
and functionality related to normal PBX does. Asterisk allows to expert a telephonic
system to address users own specific requirements. The libraries of basic telephonic
functions handle the call routing in Asterisk. System triggers these libraries of
functions through digital patterns referred to extensions, to complete the call routing
processes. For interconnection between digital and analog telephony equipment,
Asterisk does Voice over IP in many protocols, call setup and voice streaming
protocols are example. It provides transport bridging between Voice over IP
protocols including SIP, H.323, IAX, MGCP, and also support traditional circuits like
TDM, T1/E1, POTS, BRI and PRI. [6][7][8]
6.1 Asterisk Detailed Architecture

Asterisk is designed for maximum flexibility and interconnection; number of library
functions handles call processing in Asterisk. The central core of Asterisk consists of
several engines to perform these functions shown in figure 6-1, each of them play
special role to complete the software operations. Asterisk architecture is relatively
very simple to other PBX; specific API’
s are defined around the central PBX core,
the core handles the internal interconnection of the PBX. [6][7][9]

E3393D
C ustom er A pplications , V oice m ail

P aging , C onferencing , D irectory, D ialing
A sterisk A pp lication A P I
Asterisk File Format API

C odec
Codec Translator API
T ranslator
G .723s f
GS M S ched uler
G .7 23 and G S M sf
M u -Law A pplication
Linear A - I/O W av e
Law
L aun cher
M a nag er
ADPCM M P3
M P3
PBX AU
Sw itching D ynam ic
C ore M odule
Loader
A sterisk C h annel A P I
A dtra n V oF R IS D N V oice m odem S IP H 3.23

C u stom h ardw are
Figu re 6-1, A sterisk d etail A rch itectu re [6]
Asterisk Core Components

Asterisk core performs call operations in number of steps, described in Fig 6-1. [9]
Dynamic Module Loader is the engine that works at the start of Asterisk. Dynamic
module loader loads and initialize all the drivers for channels, file format, call detail
record back ends, codecs, applications and more, linking them with appropriate
internet API’
s.
PBX Switching Core is an important engine of Asterisk core, it accept calls from
interfaces and handling them according to instructions found in dial plans.

E3393D
Application Launcher The PBX switching core uses the application launcher for
ringing phones, connecting to voicemail and dialing out outbound trunks.
Scheduler and I/O Manager is a core component engine that provides environment
to applications and drivers to take advantage of Asterisks.
Codec Translator The main purpose of codec translator is to allow the differently
compressed coded channels to talk with one another.
Asterisk Interfaces and Channels

In Asterisk, Incoming and outgoing calls are handled through interfaces. Different
types of interfaces are associated with different kind of hardware or protocols, for
example SIP, Zaptel, and IAX. There are four main interfaces defined in Asterisk
architecture shown in figure 6-1, Channel API, Application API, Codec translator
API, File format API. [6][7][8][9]
Channel API Channels are the logical entities use to connect signalling and
transmission path between end points. Every call in Asterisk is placed over an
interface in its own distinct channel. Channels are of different types based on their
nature, like physical channels (such as FXO port) or software-based (SIP, IAX). In
Asterisk, dial plans rules are used to define and connect different channels together.
Channel API is used to connect these channels in distinct fashion according to dial
plans. A channel is named usually after its interface or protocol such as SIP, IAX,
Zap for Zaptel.
Application API Asterisk supports number of application, for example voice mail,
call waiting, conferencing, Interactive voice response and automatic call distribution
etc. These all applications are available to the dial plans when processing the
incoming calls to take advantage of Asterisk PBX features and pass through the
application API.

E3393D
Codec and File format API’

s are an example of open and flexible architecture of
Asterisk. Due to open architecture, Asterisk support wide variety of codec and file
format.
Codec Translator API A codec translator API is used to translate the coded voice
or signal into desired coded voice or signal or to decompress the data packets or
analog signals, no matter where it is coming from. GSM, G.723, ADPCM and MP3
are supported.
File Format API Asterisk support wide variety of format for audio files and uses
these files to store audio data such as ring tones, music on hold and voice mail. File
format API allows Asterisk to read and play sound in different formats including
WAV, AU, and MP3. This gives Asterisk-based applications more flexibility in dealing
with ring tones, DTMF etc. [4] [2][1]
6.2 Introduction to Dial Plans

Dial plans are the heart of any Asterisk PBX system. These are the step-by-step
instructions, which Asterisk should follow for successful setup. In simple words,
Asterisk dial plans are the “road map”for the call routing processes. Asterisk dial
plans are very flexible, and allow very flexible way of routing calls. In the next
section, the fundamental of creating dial plans are described. [17]
6.2.1 Fundamentals of Dial Plans

Asterisk dial plan consist of four main parts, context, extensions, priorities,
applications. The majority of dial plans in Asterisk are specified in configuration file
extensions.conf. The configuration file “extensions.conf”contains the “dial plan”of
Asterisk, the master plan of control or execution flow for all of its operations. It
controls how incoming and outgoing calls are handled and routed. [7][8]
[Context] = <extension>, <priority>, <application>, < [args] >

E3393D
Context is an organizational part of the dial plan structure. It is the section defined
by the administrator to keep the executable instructions (extensions) separately. In
simple words, it is an auto attendant menu used to execute the referenced plan. For
example, the incoming calls context can be called when press “1”or PSTN with “0”.
The context is generally denoted by their name in the square bracket, simply
[incoming] for incoming calls and [PSTN] for pstn calls.
Extensions are defined within the context. In Asterisk, extension is a character

string, which trigger an event. In traditional PBX, the extensions referred to phone
number, interfaces, menu and so on, while in Asterisk extension is defined as a list
of applications (and argument) to run. In Asterisk extensions determine how the call
flows with some priorities and applications.
exten = > <exten>, <priority>, <application>, [<args>]
Priorities are the numbered steps in execution of Asterisk dial plans. For example if
there are more then one instructions in the sequence, the priority set the limit which
command have to execute first.
exten => 1000,1,Answer

exten => 1000,2,Playback(goodbye)
exten => 1000,3,Hangup
In this example, the number 1000 is used as an extension. When a call is made to
this extension, the first priority Asterisk will answer the number, then Asterisk will
play a good-bye message to user, and in the last priority hang up command will
execute. Asterisk code is not sequence dependent, priorities set the execution
sequence.

E3393D
Applications are used to manipulate calls and giving the user an interactive system.
Each priority calls one specific application to perform an action on voice channel,
such as playing sound, voice mail, dial, answer or hanging up the call are example
of applications. Applications perform action on behalf of the arguments passed.
There are lots of built in applications in Asterisk like Dial, hang up, answer etc.
6.3 Static and Real-time Dial Plans

Dial plans can be optimized from database (Real-time) or can pull from storage
configuration files (Static). In static or file-based configuration dial plans described in
APPENDIX B, Asterisk need to restart the services at every change in call routing
plans in configuration files. While in real-time (database) dial plans described in
APPENDIX D, Asterisk can actively reload dial plans without need to restart the
services. GUI can be used as front-end tool to assist the adding and updating the
call control statement in call routing environment of real-time system.
A principle difference between Static (flat file) and Real-time (database) system is
the way data collected and organized. A flat file is organized physically; items
proceed or follow other items. While in contrast the content of database are
organized according to the data model. In Asterisk data model is the road map,
which define the routing processes and how unit relates to each other.
Another big difference between static and real-time system is the way you access
them. In Asterisk file-system the instruction query read the file sequentially, looking
for particular vales at particular location in each time or record. In contrast, when
process the query in database it use the terms that data model defines. Simply,
when Asterisk access dial plans that are stored in a file, it sequentially read in
physical layout of the file. When it queries the database, it ignore the arcane detail of
the computer storage and state query in terms that reflect real world, at least to the
extent that the data model reflects the real world.

E3393D
The advantage of database over file system is, that it can be use the common
source for many users. Multiple users can query and modify database
simultaneously, while in file system records are updated statically.
In Asterisk, various configuration files are used to load the dial plans. For static
configuration, most commonly used files are sip.conf and extensions.conf, these files
reflects the dial plan operations in sequential order, described in APPENDIX B. The
entire configuration related static dial plan stores in both files. In Real-time
(database) system, the entire configuration related dial plans are keep updated in
database, described in APPENDIX D. For query the dial plans from the database,
some extra configuration modules are needed to install for connectivity of Asterisk
with database, such as Asterisk-add-ons, described in APPENDIX C.
6.4 Asterisk Files Organization and Configuration

Asterisk is controlled by editing a series of configuration files, these files are installed
and organized at the location /etc/Asterisk except zaptel.conf, shown in the table 1
below. “Asterisk grammar varies from one configuration file to another, however
these configuration files can generally be divided into three categories”[7][9].
INTERFACE CONFIGURATION- files are used to configure channel interfaces,

which are directly connected to the physical hardware. Examples include
adtranvofr.conf, alsa.conf, modem.conf, oss.conf, phone.conf, and zapata.conf.
SIMPLE GROUPS – files simply define the existence of various entities, like
mailboxes, conference rooms, etc. Examples include extensions.conf, logger.conf,
meetme.conf, musiconhold.conf, parking.conf, and voicemail.conf.
INDIVIDUAL ENTITIES - These types of configuration files are used most often for
VoIP services. Examples include iax.conf, oh323.conf, and sip.conf.

E3393D
The following table describes the location, where Asterisk associated file stores [1].
/etc/Asterisk All configuration files except /etc/zaptel.conf
/etc/sbin Asterisk executable and scripts including Asterisk,

astman, astgenkey and safe Asterisk.
/usr/lib/Asterisk/ Asterisk architecture specific binary objects.
/usr/lib/Asterisk/modules Runtime modules for applications, channel driver, codes,

file format driver etc.
/usr/include/Asterisk Header files required for building Asterisk applications,

channel divers and other loadable modules.
/var/lib/Asterisk Variable data used by Asterisk during normal application.
/var/lib/Asterisk/agi-bin AGI scripts used by the dial plan AGI application.
/var/lib/Asterisk/astdb The Asterisk database holds configuration information.

This file is never changed by hand. Use Asterisk
database command line functions to change, add to and
modify this file.
/var/lib/Asterisk/images Image referenced by the application or by the dial plan.
/var/lib/Asterisk/keys Private and public keys used within Asterisk for RSA
authentication. IAX uses keys stored here.
/var/lib/Asterisk/mohmp3 MP3 files used for music on hold. The configuration for
music on hold is found in the directory
/var/lib/Asterisk/sounds.
/var/lib/Asterisk/sound Audio files, prompts, etc. used by Asterisk applications.

Some applications may hold their files in subdirectories.
/var/run Run time named pipes and PID files.

E3393D
/var/run/Asterisk.pid Primary Process Identifier (PID) of the running Asterisk

process.
Table 1, Asterisk File organization and configuration [1]
Table 1 presents the whole structure of Asterisk file organization while its
configuration details are in APPENDIX A.

E3393D
7 Experimental Setup and Analysis

This thesis study is to analyze the performance of Asterisk. For this purpose,
different experimental setups were conducted. The experiments were originally
designed for the testing and verifying the functionality of the Asterisk version 1.2.7.1
in comparison of static and real-time dial plans with output parameter such as upper
call success limit and CPU utilization.
7.1 Experimental Setup Overview

In the Lab scenario, two different speed Asterisk servers were configured on Linux,
for performance investigation of each, shown in figure 1-1. These servers present
the whole scenario of enterprise VoIP network, by communicating to each other and
connected IP phones.
For the performance evaluation of a single Asterisk server shown in figure 7-1, it was
impossible to measure the performance with 1000 or more connected IP phones, so
traffic generator software was used to generate and receive the SIP calls. Two new
and fast computers are being used as SIP calls generator (computer A) and SIP
calls receiver (Computer B). Burst of calls (number of calls/sec) from the total
number of calls offered was generated to the Asterisk server, and after processing
from Asterisk server; the calls are being forwarded to the Logical SIP Phones at SIP
Calls receiver. The signal, connectivity, load and call success rate were measured
and analyzed by number of calls completed and summary reports from WINSIP
Software [1]. The performance of hardware parameters such as, CPU and memory
utilization of the server is measured by third party tool named windows application
manager 6 (Computer C), by creating the secure SSL connection. This software’
s
are discussed in detail in the next chapter.

E3393D
A s t e r is k S e r v e r
100 Mbps
100 M bps 100 M bps
` `
S IP C A L L G E N E R A T O R (C o m p u te r A ) S IP C A L L R E C E IV E R (C o m p u te r B )
100 Mbps
`
S E R V E R M O N IT O R I N G T O O L ( C o m p u te r C )
F ig u r e 7 -1 , E x p e r im e n t S e tu p O v e r v ie w
7.2 Software used in Experiments
In this section software used in experiments are described in detail, two main piece
of software are used for testing and performance evaluation of the system, WINSIP
for Call generation and emulation and Application Manager6 for monitoring the
performance of hardware components of the Asterisk.
7.2.1 Call Generation and Emulation (WINSIP)
The “WINSIP – SIP call generation and Emulation” [15], a Software is a SIP
connection and real-time call generation tool for VoIP network. It is the window-
based application to generate, receive and monitor the SIP calls. It performs several
modes of operation, like Initiate calls, answer calls, unattended answer, registrar
testing and proxy server. It has ability to diagnose signal, connectivity, load, call and

E3393D
session summary report etc. WINSIP provides the comprehensive VoIP call matrices
(connected calls, success and failure), Initial response latency, post dial delay, ring
duration, media start delay and tear down time etc.
As, WINSIP places actual calls; we used it in the same manner as the normal IP
phone does. In the initiation mode of operation, SIP generated traffic (hundred to
thousands of calls) can route to the application server (Asterisk). For SIP traffic, user
selects the total number of calls, throughput (calls/sec), phone numbers of the
senders and receivers incrementally or fixed, IP address of sender and receiver with
same communication port number, inter packet delay and timing can also be set.
The important parameter in the call establishment is RTP media streaming; it can set
by selecting send only, mirror or via options to send or receive the select coded
media traffic. SIP generated traffic can save in files, and remains available to view
the call establishment matrices from the log-generated file.
In the answer mode of operation, the SIP calls are received at number of logical
phones, from the application server. In this mode of operation all the properties are
set according to the initiation mode but in reverse. The receiver address becomes
the sender address and vice versa. For the answer mode, IP address of the receiver
and sender of the application are also set with same port number.
In this experimental setup, WINSIP is not only used to generate and receive the SIP
traffic, but also provides the comprehensive summary report about call processing
features, specifically the call success rate.
7.2.2 Server Performance Measurement Tool
Application manager is a web-based performance monitoring tool [16], that runs at

peak of performance monitoring of server objects like CPU, memory, processes,
disk utilization, disk I/O stats etc. Application manager provide out-of-box monitoring
capability of server health to reveal performance and availability information for both

E3393D
hardware and software components. In this thesis work, the CPU and memory
utilization of Linux based Asterisk server is examined against Asterisk call load.
“Monitoring a VoIP server means watching the hardware, the operating system, the
major application running on the server.” [1] The operating system may include,
Windows, Linux and Solaris. Applications include web servers, databases, and file
transfer services.
In description of monitored elements, the CPU monitoring refers to maximum CPU

utilization threshold exceeded per application and across the entire system. It also
observes the amount of physical memory usage per application and across the
entire system. The disk utilization percentage with operation maximum time for read
and writes are under investigation.
7.3 Experimental Setup Details

In this section experimental setup details are described. Asterisk is installed in the
Cuuma communications Oy laboratory to test the static and real-time (database) dial
plans features. The verification of system was planned for the upper limit of calls and
CPU utilization applicability in the real business world. Experiments are conducted
with two different processing speed systems to verify the Asterisk features. For the
performance evaluation of a single Asterisk, experimental setup is divided into three
phases. In phase1, the implementation and working of Asterisk with other Asterisk’
s
and IP phones is confirmed. In the second phase of the project the software used for
testing are chosen, installed and configured to generate, receive the calls and
monitor the performance of the server. In the last and final phase of the experimental
setup, variable numbers of burst calls are generated to measure the performance of
the single Asterisk. In this section, the performance of the Asterisk is measured
based on first two phases. Results are analyzed based on collected raw statistics
from static and real-time systems with extreme testing of Asterisk, and decision is

E3393D
made on these results. The whole experimental setup is divided into four test
scenarios, described below in detail.
7.3.1 Test Scenario 1

In Test Scenario 1, Asterisk performance is evaluated with static dial plan
configuration features. The main purpose of test scenario 1 is to fully load the
Asterisk server to find out the maximum call serving capacity and CPU utilization
(goes near to 100%) on 350 MHz machine. Asterisk is a black box; no one knows
about the exact call serving capacity. [18] In this test scenario, three fast speed
machines are used to measure the performance of statically configured Asterisk.
For static dial plans many files have to be configured. A static configuration in
Asterisk is referred to the file system configuration. All the configuration files of
Asterisk file system resides at the location of /etc/Asterisk distribution in Linux. The
file is defined within the Asterisk program and organized physically with configuration
dial plans. In Asterisk file system, certain items precede or follow the other items to
make successful call plans. In static configuration of Asterisk, all the call plans are
retrieved from the distributed configuration files (like sip.conf and extensions.conf),
and need to reload Asterisk every time with some configuration changes in these
files. The definition and configuration of these files is attached in APPENDIX B.
Test Scenario1 shown in figure 7-2, experiment setup equipment consists of

statically configured Asterisk version 1.2.7.1 machine, running on Linux fedora core
4 as an operating system with the processor speed of 350MHz and 256MB of RAM
and equipped with 6GB hard disk. In this experiment, three fast computers with
processor speed of 2.4GHz of each with 512MB of RAM, running on Microsoft
windows XP as an operating system are used, with the physical link of 100 Mbps at
each ends of the connection to send, receive and investigate the SIP signaling and
real-time media using UDP/TCP protocols, from SIP call generator (computer A) to
Asterisk server and from Asterisk server to SIP call receiver (computer B). Burst of
variable calls (calls/sec) are generated to evaluate the performance of the static

E3393D
server. The server health and availability is examined through secure SSL
connection, at the threshold level through third party tool, Application Manager6 [16]
(computer C), described in section 7.2.
In test scenario 1, fifteen different experiments were conducted to analyze the

performance of Asterisk by generating 200 number of calls with bursts of calls
between 1 to 15 (calls/sec), with audio encoded media of G.711 u-law (PCM 64
kbit/s bit stream) using the SIP protocol for inbound and outbound calls, to find out
the best call serve rate and CPU utilization in figures, table 1 and 2 in APPENDIX E
summarize the test results.
100 M bps 100 M bps

` `
C OM PUTER A C OM PUTER B
A s te ris k P B X
100 Mbps
COMPUTER C
F ig u r e 7 -2 , T est S c en a r io 1 S e tu p O v e rv ie w

E3393D
7.3.2 Test Scenario 2

Test Scenario 2 is exactly the same as Test Scenario 1, same stimuli were used but
the observation were taken for the Asterisk real-time (database) behavior, to find out
the call serving capacity and CPU utilization of loaded Asterisk on same speed
machine of 350 MHz. In the real-time configuration of Asterisk, all the configuration
regarding registration and call plans are saved, updated and retrieved from the
database and no need to reload Asterisk all the time even configuration changes
take place in database.
In Test Scenario 2, MYSQL database version 5 was installed with Asterisk add-ones
modules to support MYSQL connectivity and working with Asterisk. Various
configuration changes were made for data retrieval and access plans from database,
attached in APPENDIX C.
In Test Scenario 2, experiment setup consists of real-time (database) configured

Asterisk version 1.2.7.1, running on Linux fedora core 4 as an operating system and
MYSQL distribution 5.0 as database backend, with the processor speed of 350MHz
and 256MB of RAM and equipped with 6GB hard disk. In this experiment, three fast
computers with processor speed of 2.4GHz of each with 512MB of RAM, running
Microsoft windows XP as an operating system are used, with the physical link of 100
Mbps at each ends of the connection to send, receive and investigate the SIP
signaling and real-time media using UDP/TCP protocols, from SIP call generator
(computer A) to Asterisk server and from Asterisk server to SIP call receiver
(computer B). Burst of variable calls (calls/sec) are generated to evaluate the
performance of the real-time configured Asterisk server. The server health and
availability is examined at threshold level, through third party tool application
manager6 with secure SSL connection (computer C), described in section 7.2.

E3393D
The experimental features such as, the upper call limit and CPU utilization is
observed carefully with the help of monitoring software’
s. The gathered statistical
information is analyzed based on real-time experiment results.
For Asterisk real-time dial plans, fifteen different experiments were conducted to
analyze the performance of real-time (database) configured Asterisk by generating
200 number of calls with different number bursts of calls between 1 to 15 calls per
second, with encoded media of G.711 u-law and 20 ms of packet size using the SIP
for inbound and outbound calls, to find out the best call serve rate and CPU
utilization in figures, table 3 and 4 in APPANDIX F summarize the test results.
D a ta b a s e
100 M bps 100 M bps

` `
S IP C A L L G E N E R A T O R ( C o m p u te r A ) A s te r is k S e r v e r S IP C A L L R E C E IV E R (C o m p u te r B )
100 Mbps
S E R V E R M O N IT O R IN G T O O L (C o m p u te r C )
F ig u r e 7 -3 , T e s t S c e n a r io 2 S e t u p O v e r v ie w

E3393D
7.3.3 Test Scenarios 3 and 4

Test Scenario 3 and 4 are performed on 2.4 GHz processing machine with 256MB of
RAM and equipped with 80 GB hard disk to test the Asterisk static and real-time dial
plans, to find the upper call limit and CPU utilization. Entire Experimental setup for
both test scenarios is exactly same as Test Scenarios 1 and 2, but tests are
conducted with the fast speed machine of 2.4 GHz.
To test the Asterisk static and real-time features at 2.4 GHz machine, ten different
experiments were conducted for each to analyze the performance of Asterisk for
both dial plans by generating 500 number of calls with different number bursts of
calls between 10 to 30 calls per second, with encoded media of G.711 Ulaw, to find
the best call serve rate and CPU utilization in figures, table 5 and 6 in APPANDIX G
summarize these test results.
8.0 Results Analysis

This section of the thesis presents the results of tests and analysis performed on the
Asterisk IP PBX. In this section the recorded results of previously described test
scenarios are investigated and analyzed.
8.1 Results of Test Scenario 1
The main purpose of test scenario 1 was to investigate upper call limit and CPU
utilization of fully loaded static Asterisk on 350 MHz machine. Fifteen different
experiments were conducted against calls/sec to gather raw call statistics and CPU
utilization to carefully analyze the performance of Asterisk. This section gives the
overall assessment and analysis of recorded results. The Test Scenario 1 is divided
into two phases, phase 1 represents the static Asterisk behavior without system

E3393D
restart and phase 2 verifies the results by continuously restart the system for every
experiment, described in next section.
Phase 1 illustrates the static Asterisk results without system restart, shown in Figure
8-1. The Figure presents the results of successful calls and CPU utilization against
15 different bursts (calls/sec), while total numbers of calls offered are 200 for every
experiment. The blue dot in the figure indicates the successful calls result and pink
dot displays the CPU utilization against specified bursts (calls/sec). It can be seen
from figure, the Increase in bursts from 1 to 15 (calls/sec) the successful calls limit
decreases and CPU utilization goes up to 100%. After some point, the successful
calls limit decreases with the increase in CPU utilization, even a fall down in a graph
can be seen. There are some investigation question arises, Is this due to some
running services on CPU or Asterisk structural behavior affects the performance?
To verify the question, same methodology was used with system restart, described
in phase 2.
Asterisk Static, Calls and CPU utililzation vs Calls/Sec

Successful calls and CPU
160
140
120
utilization
100 Successful Calls

80
CPU Utilization
60
40
20
0
0 5 10 15 20
Calls/Sec
Figure 8-1, Static Asterisk results without system restart
Phase 2 uses the same stimuli, but the results are recorded with the continuous
restart of the system for every experiment. The Figure 8-2 illustrates the recorded
results, blue dots in the figure represent the successful calls, while pink dot indicates

E3393D
the CPU utilization against different bursts (calls/sec). The burst range is set from 1
to 15 while the total numbers of calls offered are 200 for every experiment. It can be
observe from the figure 8-2 that the results of phase 2 are still close enough to the
actual results of phase1, but there is some abnormal behavior in the CPU utilization,
the call success rate is continuously decreasing with increase in bursts (calls/sec).
The call success limit at the specified burst for both phases is almost same at 100%
CPU utilization. The analysis on these results is described in section 8.3.
Asterisk Static, Calls and CPU utililzation vs Calls/Sec

160
140
120
utilization
100
Successful Calls
80
60 CPU Utilization
40
20
0
0 5 10 15 20
Calls/Sec
Figure 8-2, Static Asterisk results with system restart
8.2 Results of Test Scenario 2

Test Scenario 2 is same as Test Scenario 1, same methodology was used but the
observation were taken for the real-time (database) behavior, to find out the upper
call limit and CPU utilization of loaded Asterisk on same speed machine of 350 MHz.
In Test Scenario 2, fifteen different experiments were conducted against calls/sec to
gather raw call statistics and CPU utilization to carefully analyze the performance of
real-time configured Asterisk. Test Scenario 2 is further divided into two phases,
below figure 8-3 represents the real-time Asterisk behavior without system restart
while figure 8-4 represents the real-time Asterisk behavior with system restart.

E3393D
Phase1 refers to the results of real-time Asterisk without system restart, described in
Figure 8-3. It is shown in figure 8-3, the successful calls are decreasing with the
increase in calls/sec while at some point CPU utilization drop down with some
abnormal behavior, described in result analysis.
Asterisk real-time Calls and CPU utililzation vs Calls/Sec

200
150
utilization
Successful Calls
100 CPU Utilization
50
0
0 5 10 15 20
Calls/Sec
Figure 8-3, Real-time Asterisk results without system restart
Phase 2, presents the results of dynamic Asterisk with system restart at every
experiment to verify the results of phase 1, shown in Figure 8-4. The figure shows,
the successful calls are decreasing with increase in burst size (calls/sec) and CPU
utilization is decreasing after threshold level 100% and showing abnormal behavior
at every restart of the experiment at new burst.

E3393D
Asterisk real-time Calls and CPU utililzation vs Calls/Sec

250
200
utilization
150 Success ful Calls

100 CPU Utilization
50
0
0 5 10 15 20
Calls/sec
Figure 8-4, Real-time Asterisk results with system restart
8.3 Results of Test Scenario 3 and 4

Test Scenario 3 and 4 are same as Test Scenario 1 and 2, same methodology used
and observation was taken for both static and real-time (database) behavior, to find
out the upper call limit and CPU utilization of loaded Asterisk on fast speed machine
of 2.4 GHz. In these Tests Scenarios, Ten different experiments were conducted
against calls/sec to gather raw call statistics and CPU utilization. Figure 8-5
represents the static Asterisk behavior of the system while figure 8-6 represents the
real-time dial plan results.
In Test Scenario 3 Asterisk static dial plans performance is evaluated shown in

figure 8-5, the successful calls are decreasing with the increase in calls/sec while
CPU utilization increasing to 100% with the increase in calls/sec bursts and remain
constant after some point.

E3393D
Asterisk Static at 2.4 GHz

Successful Calls and CPU
600
500
utilization
400
Successful Calls
300
CPU utilization
200
100
0
0 5 10 15 20 25 30 35
Calls/Sec
Figure 8-5, Static Asterisk results at 2.4 GHz
In Test Scenario 4 Asterisk real-time dial plans are verified shown in figure 8-6, At
some point the successful calls are decreasing with the increase in calls/sec while
CPU utilization showing an abnormal behavior after 100% with the increase in
calls/sec bursts.
Asterisk Dynamic at 2.4 GHz
600
Successful Calls and CPU
500
400
utilization
300 Successful Calls

200 CPU utilization
100
0
-100 0 5 10 15 20 25 30 35
Calls/Sec
Figure 8-6, Dynamic Asterisk results at 2.4 GHz

E3393D
8.4 Results Analysis

From the above-mentioned results, following points are deduced.
• In Static test experiments, shown in figure 8-1 and 8-2, it is analyzed that the
best call serving capacity of Asterisk 1.2.7.1 with static configuration at 350
MHz machine is 4 calls/sec. The successful calls ratio is about 140 calls and
CPU utilization goes to 100%. As number of calls per second increases, CPU
utilization increases to 100 % and then remains constant (limit to 100 %) after 4
calls/sec, while number of successful calls decreases.
• In comparison of 3 calls/sec, where the successful calls limit and CPU

utilization is even most optimized, shown in figure 8-1 but it serves less number
of calls/sec that is preferably not good in real telephony business. While at 5
calls/sec, bottleneck reaches with the drop in successful calls and the CPU
utilization at 100 %, it is also not worthwhile in VoIP telephony business.
• Another key point, which is observed during static test experiments from figure
8-2, there is sudden change in CPU utilization, which shows an abnormal
behavior. CPU utilization decreases at 5 calls/sec. It might possible due to
some processes, which are running on CPU. It can be concluded, as “Asterisk
main weakness is uncertainty about how much host CPU is available at any
given instant. PC operating system don’
t do a job of guaranteeing that a
specific amount of CPU and memory will be available at any moment”. [14]
• It is concluded from static test experiments that successful calls are not
effected with and without system restart for Asterisk. The best calls serving
capacity of Asterisk with static configuration is limited to the 4 calls/sec at 350
MHz servers with 100% CPU utilization.
• In dynamic test experiments from figure 8-3 and 8-4, it is analyzed that the best
result is at 3 calls/sec for 350 MHz machine. The successful calls limit is about

E3393D
150 calls and CPU utilization goes to 100%. It is observed that, without restart
of Asterisk real-time server number of successful calls decreases while CPU
utilization remains constant at 100 % with the increase in calls/sec.
• In real-time test experiments, described in figure 8-4. It is observed that with

restart Asterisk dynamic server number of successful calls decreases as well
CPU utilization also simultaneously decreasing with the increase in number of
bursts (calls/sec).
• During real-time test in figure 8-3 and figure 8-4, it is observed that there is
sudden change in CPU utilization, which shows an abnormal behavior. CPU
utilization decreases at 9 calls/sec. It might be possible due to some processes,
which are running on CPU.
• It is concluded from real-time test experiments that successful calls are not
effected with and without system restart for 350 MHz of Asterisk server. The
best calls serving capacity of Asterisk with real-time configuration is limited to
the 3 calls/sec at 350 MHz servers with 100% CPU utilization.
• In Static test experiments at 2.4 GHz machine shown in figure 8-5, it is

analyzed that all calls are successfully served at 18 calls/sec and CPU
utilization goes to 100%. After 18 calls/sec CPU utilization remains constant up
to 100%, while successful calls decreases with increase in calls/sec.
• In comparison of 17 calls/sec, where the successful calls limit and CPU

utilization is even most optimized, shown in figure 8-5 but it serves less number
of calls/sec that is preferably not good in real telephony business. While at 19
calls/sec, bottleneck reaches with the drop in successful calls and the CPU
utilization at 100 %, it is also not worthwhile in VoIP telephony business.
• In real-time test experiments at 2.4 GHz machine shown in figure 8-6, it is

analyzed that all calls are successfully served at 15 calls/sec and CPU

E3393D
utilization goes to 100%. After 15 calls/sec CPU utilization suddenly decreases

at 7%, which shows an abnormal behavior of Asterisk Server.
9 CONCLUSION AND FUTURE WORK

The Objective of the project work is achieved by analyzing the performance of
Asterisk VoIP server, for business purposes. The idea of static and real-time
(database) dial plans is used to verify the upper call success limit as function of CPU
utilization. From the experiment results, it is concluded that Asterisk is platform
dependent for static and real-time dial plans to handle the number of simultaneous
calls because “Asterisk main weakness is uncertainty about how much host CPU is
available at any given instant. PC operating system don’
t do a job of guaranteeing
that a specific amount of CPU and memory will be available at any moment”. [14]
As, Asterisk behaves as transit switch instead being a user. The call load causes
Asterisk switching congestion result in, calls failure or unspecified.
Based on actual experiments, conclusion is drawn that Static dial plans are more
suitable for both machines used in experiments as compared to real-time dial plans
because it serves maximum calls/sec during experiments as a function of CPU
speed, which is a key point for VoIP business industry. However as processing
power of the machine will increase, performance of real-time dial plans supposed to
be improved.
It is clearly analyzed from experiments that static results are most optimized as in
sense it serves maximum calls against real-time dial plans. But in real VoIP
telephony business where billions of users are served at the same instance, it is not
statically possible to serve them. Here company will prefer dynamic dial plans.
Future work could be done by improving the performance of Asterisk. SIP Express
Router is a solution; Asterisk performance can be improved by dynamic load
balancing of incoming calls according to redundant nodes when CPU utilization
exceeds the specified threshold.

E3393D
REFERENCES
[1] Walker, Hicks, Taking Charge of your VoIP Project, Cisco Press-ISBN 1-58720-
092-9.
[2] Coombs, Coombs, Communications Network Test and Measurement Handbook,

McGraw-Hill Companies ISBN 1-58720-092-9.
[3] E Brinksma, H Hermanns, Lectures on Formal Methods and Performance

Analysis, ISBN 3-540-42479-2.
[4] Paul Fortier, Howard Michel, Computer System Performance evaluation and
Prediction, ISBN 1-55558-260-8.
[5] Hossien Noshin (2005), Developing a Performance Model for Staselog Network
Equalizer (NE), Helsinki Polytechnic Stadia.
[6] Paul Mahler, VoIP Telephony with Asterisk, ISBN- 09759992-0-6.
[7] The Asterisk handbook version 2, Digum 2003, www.digium.com
[8] The Hitchhiker’

s Guide to Asterisk, www.Asteriskdocs.org (Read 02, August
2006)
[9] Asterisk Guide for Newbie’

s, (Read 1,August 2006)
http://www.iareaphone.com/Downloads/Asterisk_config.pdf
[10] Jan Janak, SIP Introduction, 2003. www.iptel.org
[11] The Internet Engineering Task Force (IETF), http://www.ietf.org/rfc/rfc3261.txt
[12] SIP education, http://mit.edu/sip/sip.edu/started.shtml (Read 16,July 2006)

E3393D
[13] SIP, Cisco Systems (Read 10, July 2006)

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-1/sip.html
[14] www.onlamp.com/pub/a/onlamp/2005/06/23/pbx.htm (Read 28, July 2006)
[15] Touch Stone Inc, www.touchstone-inc.com
[16] Advent Net, http://manageengine.adventnet.com/products/applications_manager/
[7] VoIP info, www.voip-info.org (Read, 10, July 2006)

E3393D
APPENDICES
APPENDIX A: Asterisk Installation and Configuration
APPENDIX B: Asterisk Static Dial plan Configuration
APPENDIX C: MySQL and add-ones for Asterisk Real-time
APPENDIX D: Asterisk Real-time Dial plan Configuration
APPENDIX E: Test Scenario 1 Results (Asterisk Static)
APPENDIX F: Test Scenario 2 Results (Asterisk Real-time)
APPENDIX G: Test Scenario 3 and 4 Results (2.4 GHz)

E3393D
APPENDIX A: Asterisk Installation and Configuration
Asterisk is an open source PBX (Private Branch Exchange). A PBX manages calls
between internal or local users. It shares often a number of lines that connect to the
external, public network.
Install Asterisk
1. Go to the download directory
# cd /usr/local/download/
2. Download Asterisk tarball
# wget http://ftp.digium.com/pub/Asterisk/Asterisk-1.2.7.tar.gz
3. Untar the tarball
# tar -xvzf Asterisk-1.2.7.tar.gz –C /usr/local/src/
4. Go to the source file
# cd /usr/local/src/Asterisk-1.2.7/
5. Build Asterisk
# make
# make install

E3393D
6. Install sample configuration, this will copy a set of sample configuration

files to your /etc/Asterisk directory.
# make samples
7. Install documentation
# make progdocs
8. Start Asterisk
# /usr/local/src/Asterisk-1.2.7/Asterisk start
9. Add the line above to /etc/rc.local
10. Check if Asterisk is started
# ps aux |grep Asterisk

E3393D
APPENDIX B: Asterisk Static Dial plan Configuration
1. Go to the Asterisk directory with the configuration files
# cd /etc/Asterisk/
Sip.conf
A block of text in the sip.conf file identifies each SIP client and server. Here is the
configuration example of two connected IP phones on LAN.
2. Edit the sip.conf file
# kedit sip.conf
3. Add the following lines to the file
[grandstream1]
type=friend ; either "friend" (peer+user), "peer" or "user"
context=from-sip
username=grandstream1; usually matches the section title
password=grandstream1;
host=dynamic ; we have a static but private IP address
nat=yes ; there is not NAT between phone and Asterisk
canreinvite=yes ; allow RTP voice traffic to bypass Asterisk
disallow=all ; need to disallow=all before we can use allow=
allow=ulaw ; Note: In user sections the order of codecs
allow=alaw ;
[grandstream2]

E3393D
context=from-sip
username=grandstream2; usually matches the section title
password=grandstream2;
host=dynamic ; we have a static but private IP address
allow=alaw ;
; This section is for SIP incoming calls from SIP generator
[Incoming]
context= incoming
username= Asterisk; usually matches the section title
password= Asterisk;
host= 10.19.200.92 ; we have a static but private IP address
port=5060;
allow=alaw ;
[outgoing]
context= outgoing
username= grandstream1; usually matches the section title

E3393D
host= 10.19.200.84 ; we have a static but private IP address

port= 5060;
allow=alaw ;
Extensions.conf
The extensions.conf file contains the dial plan of Asterisk. In the extensions.conf file
is described how incoming and outgoing calls are handled and router. You configure
in this file the behavior of all connections through your PBX.
The context [default] permits dialing the listed extensions.
The context [local] permits the listed extensions to dial 7-digit numbers only. It also
includes the context [default].
The context [long distance] permits to dial a long-distance call. It includes also the
context [local].
Each step in an extension has the following format:
exten => extension, priority, Command(parameters)
The Dial command has to following parameters:
Dial(type/identifier, timeout, options, URL)

E3393D
4. Edit the extensions.conf file
# kedit extensions.conf
5. Add the following lines to the file
[default]
include => from-sip
include => incoming
include => outgoing
[From-sip]
exten => 2500,1,Dial(SIP/grandstream1,10)
exten => 2600,1,Dial(SIP/grandstream2,10)
[outgoing]
exten => _XXX,1, Dial(SIP/${EXTEN}@outgoing)
6. Restart Asterisk or the server
# usr/local/src/Asterisk-1.2.6/Asterisk –r
cli>sip reload
cli>exit

E3393D
APPENDIX C: MySQL and add-ones for Asterisk Real-time
Installation of MySql
1. Download the source file:
a) cd /usr/local/download/
b) wget ftp://ftp.belnet.be/mirror/ftp.mysql.com/Downloads/MySQL-
5.0/mysql-5.0.18.tar.gz
2. Untar the source file:
tar -xzvf mysql-5.0.18.tar.gz -C /usr/local/src/
3. Make a Mysql user. The mysql process runs under this username:
groupadd mysql
useradd -g mysql -c "MySQL server" -s /sbin/nologin mysql
4. Compile MySql. –prefix specifies the directory you want to install to.
The second part of the command tells the mysql server it needs to run
under the “mysql” username.
cd /usr/local/src/mysql-5.0.18/
./configure --prefix=/usr/local/mysql/ --with-mysqld-user=mysql
Make
Make install
5. Some configuration that needs to be done

a) cp support-files/my-medium.cnf /etc/my.cnf
This is a crucial configuration file, it contains all mysql configuration.
b) cd /usr/local/mysql/

E3393D
c) ./bin/mysql_install_db
This installs the necessary databases needed for mysql to run.
d) chown -R root .
e) chown -R mysql var
f) chgrp -R mysql .
These commands set the proper access rights on the folders that mysql
uses. If the server won’
t start, this is the first thing you should be checking!
6. Start the server:

a) chmod +x /usr/local/src/mysql-5.0.18/support-files/mysql.server
This gives the script that starts mysql execution rights.
cp /usr/local/src/mysql-5.0.18/support-files/mysql.server
/etc/rc.d/init.d/mysql
This command copies the script from the mysql source directory to the mysql
installation directory
/etc/rc.d/init.d/mysql start
7. Following links are usually made by the “make install” command.

However, sometimes they are not… Lets make sure they exist:
a) ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql
b) ln -s /usr/local/mysql/bin/mysqladmin /usr/bin/mysqladmin
(If you get an error that they already exist, everything is fine. If you do not get the
error, everything will be fine if you executed the above commands)
8. Take care of the security and set and mysql root user password:
mysqladmin -u root password St4d14
This password should NOT be the same as the normal root password!

E3393D
You should test if the password was accepted by issuing the command:
mysqladmin version –p
d) Normally, you should be prompted for a password. Enter the password
you just configured and you will see some version information.
9. Now make sure mysql boots at startup, using symbolic links to the
mysql server file. We will make a link for runlevel 3 (text based linux)
and runlevel 5 (gui)
a) ln -s /etc/rc.d/init.d/mysql /etc/rc.d/rc5.d/S20mysql
b) ln -s /etc/rc.d/init.d/mysql /etc/rc.d/rc5.d/k08mysql
c) ln -s /etc/rc.d/init.d/mysql /etc/rc.d/rc3.d/S20mysql
d) ln -s /etc/rc.d/init.d/mysql /etc/rc.d/rc3.d/k08mysql
e) Reboot and check if the server is up and running. You can test this by issuing this
command: Shell> mysqladmin version –p
Asterisk-addons Installation
1. Go to the download directory
# cd /usr/src
2. Download Asterisk addons
svn co http://svn.digium.com/svn/Asterisk-addons/trunk Asterisk-addons
3. Go to the source file
# cd /usr/src/Asterisk-addons

E3393D
4. Build and install addons
# make
# make install
After installation of addons, Copy Asterisk-addons/configs/res_mysql.conf.sample to

etc/Asterisk/res_mysql.conf Edit this file to your liking. At this time, the MySQL
drivers support multiple databases on only one server.

E3393D
APPENDIX D: Asterisk Real-time Dial plan Configuration
Real-time provides the possibility to put configuration files in a database. It makes it

easy to configure the Asterisk server through external programs, scripts and
WebPages.
Asterisk Real-Time SIP Clients and server
1. Add the following lines to extconfig.conf
# kedit /etc/Asterisk/extconfig.conf
sipusers => mysql,Asterisk,sip_buddies
sippeers => mysql,Asterisk,sip_buddies
2. Add the following lines to res_mysql.conf
# kedit /etc/Asterisk/res_mysql.conf
[general]
dbhost = 127.0.0.1
dbname = Asterisk
dbuser = Asterisk1
dbpass = Asterisk1
dbport = 3306
dbsock = /tmp/mysql.sock
3. Create the table sip_buddies in the database Asterisk

E3393D
# /usr/local/mysql/bin/mysql -p
4. If the database Asterisk doesn’t exist you have to create it first
mysql> create database Asterisk;

mysql> use Asterisk;
5. Create the table sip_buddies
mysql> CREATE TABLE `sip_buddies`

(ìd` int(11) NOT NULL auto_increment,
`name` varchar(80) NOT NULL default '',
àccountcode` varchar(20) default NULL,
àmaflags` varchar(13) default NULL,
`callgroup` varchar(10) default NULL,
`callerid` varchar(80) default NULL,
`canreinvite` char(3) default 'yes',
`context` varchar(80) default NULL,
`defaultip` varchar(15) default NULL,
`dtmfmode` varchar(7) default NULL,
`fromuser` varchar(80) default NULL,
`fromdomain` varchar(80) default NULL,
`fullcontact` varchar(80) default NULL,
`host` varchar(31) NOT NULL default '',
ìnsecure` varchar(4) default NULL,
`language` char(2) default NULL,
`mailbox` varchar(50) default NULL,
`md5secret` varchar(80) default NULL,
`nat` varchar(5) NOT NULL default 'no',
`deny` varchar(95) default NULL,

E3393D
`permit` varchar(95) default NULL,

`mask` varchar(95) default NULL,
`pickupgroup` varchar(10) default NULL,
`port` varchar(5) NOT NULL default '',
`qualify` char(3) default NULL,
`restrictcid` char(1) default NULL,
`rtptimeout` char(3) default NULL,
`rtpholdtimeout` char(3) default NULL,
`secret` varchar(80) default NULL,
`type` varchar(6) NOT NULL default 'friend',
ùsername` varchar(80) NOT NULL default '',
`disallow` varchar(100) default 'all',
àllow` varchar(100) default 'g729;ilbc;gsm;ulaw;alaw',
`musiconhold` varchar(100) default NULL,
`regseconds` int(11) NOT NULL default '0',
ìpaddr` varchar(15) NOT NULL default '',
`regexten` varchar(80) NOT NULL default '',
`cancallforward` char(3) default 'yes',
`setvar` varchar(100) NOT NULL default '',
PRIMARY KEY (ìd`),
UNIQUE KEY `name` (`name`),
KEY `name_2` (`name`)) TYPE=MyISAM ROW_FORMAT=DYNAMIC;
6. Insert the data into the table
insert into sip_buddies

values ( 1, 'grandstream1', 'grandstream1', null,
null, 'grandstream one', 'yes', 'from-sip', null,
'info', null, null, null, 'dynamic', null, null, '1234@default',
null, 'no', null, null, null, null, '5060', null, null, null,

E3393D
null, null, 'friend', 'grandstream1', 'all', 'ulaw', 'null', 0,

'10.19.200.75', '4500', 'yes', ' ' );

values ( 2, 'grandstream2', 'grandstream2', null,
null, 'grandstream two', 'yes', 'from-sip', null,
null, null, 'friend', 'grandstream2', 'all', 'ulaw', 'null', 0,
'10.19.200.77', '4600', 'yes', ' ' );

values ( 3, 'outgoing', 'outgoing', null,
null, 'outgoing', 'yes', 'outgoing', null,
null, null, 'friend', 'outgoing', 'all', 'ulaw', 'null', 0,
'10.19.200.84', '4000', 'yes', ' ' );
Asterisk Real-Time Extensions
1. Add the following line to Extconfig.conf
# kedit /etc/Asterisk/extconfig.conf
extensions => mysql,Asterisk,extensions_table
2. Create the table extensions table

E3393D
# /usr/local/mysql/bin/mysql –p
CREATE TABLE èxtensions_table` (

ìd` int(11) NOT NULL auto_increment,
`context` varchar(20) NOT NULL default '',
èxten` varchar(20) NOT NULL default '',
`priority` tinyint(4) NOT NULL default '0',
àpp` varchar(20) NOT NULL default '',
àppdata` varchar(128) NOT NULL default '',
PRIMARY KEY (`context`,èxten`,`priority`),
KEY ìd` (ìd`)) TYPE=MyISAM;
3. Insert the extensions into the table extensions_table
insert into extensions_table values (1, 'grandstream1', '4500', 1, 'Dial','10');
insert into extensions_table values (2, 'grandstream2', '4600', 1, 'Dial','10');
insert into extensions_table values (2, 'outgoing', '_40XX', 1, '

Dial(SIP/${EXTEN}@outgoing|30)','10');

E3393D
APPENDIX E: Test Scenario 1 Results (Asterisk Static)
Table-1, Results of Static Asterisk With System Restart
Calls/Sec 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CPU% 31 60 60 10 15 26 10 10 10 10 10 10 10 10 10
0 0 0 0 0 0 0 0 0 0
Memory 16 20 21 20 19 18 17 17 17 18 14 17 16 15 17
utilization
Successful 13 13 13 14 11 11 77 70 65 71 69 50 60 58 48
Calls 8 7 6 2 4 1
Table-2, Results of Static Asterisk Without System Restart
Calls/Sec 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CPU% 29 54 80 10 10 10 10 10 10 10 10 10 10 10 10
0 0 0 0 0 0 0 0 0 0 0 0
Memory 19 19 20 20 19 19 19 18 19 19 20 19 17 20 20
utilization
Successful 15 14 14 13 11 94 83 64 62 74 32 31 26 29 24
Calls 2 4 0 6 2

E3393D
APPENDIX F: Test Scenario 2 Results (Asterisk Real-time)
Table-3, Results of Dynamic Asterisk Without System Restart
Calls/Sec 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CPU% 40 79 10 10 10 10 96 10 30 10 10 10 10 10 10
0 0 0 0 0 0 0 0 0 0 0
Memory 21 25 20 26 22 21 20 21 19 22 21 18 19 21 22
utilization
Successful 17 13 13 12 83 91 62 53 57 42 58 42 42 41 34
Calls 8 4 9 6
Table-4, Results of Dynamic Asterisk With System Restart
Calls/Sec 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CPU% 37 73 95 40 28 26 21 26 19 10 10 30 10 31 30
0 0 0
Memory 24 21 20 22 21 22 22 21 21 20 21 21 19 21 22
utilization
Successful 20 13 13 11 74 10 59 57 54 45 52 48 37 41 40
Calls 0 6 9 0 4

E3393D
APPENDIX G: Test Scenario 3 and 4 Results
Table-5, Results of Static Asterisk of 2.4 GHz

Calls/Sec 10 15 16 17 18 19 20 25 30
CPU% 16 60 67 100 100 100 100 100 100
Memory 24 21 20 22 21 22 22 21 21
utilization
Successful 500 500 480 500 500 430 418 370 346
Calls
Table-6, Results of Dynamic Asterisk of 2.4 GHz

Calls/Sec 10 15 16 17 18 19 20 25 30
CPU% 10 100 7 14 100 51 100 58 100
Memory 24 21 20 22 21 22 22 21 21
utilization
Successful 500 500 500 500 500 496 470 460 376
Calls


Kniga Trixbox

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Kniga Trixbox

Transféré par

Droits d'auteur :

Formats disponibles

Performance Analysis of Asterisk VoIP Server

with Static and Real-Time Database Call

Butt, Muhammad Faisal Nazir

Programme Reg number Extent

Helsinki Polytechnic Stadia / Cuuma Communications Oy Mr. Kari Bjorn

Dalarna University 2 Tel: 023778800

Dalarna University 3 Tel: 023778800

This thesis has been conducted in the Cuuma Communications Oy at Ruoholahti

Helsinki 21 August 2006

Butt, Muhammad Faisal nazir

Dalarna University 4 Tel: 023778800

Dalarna University 5 Tel: 023778800

5 Performance Evaluation and Analysis.................................................................................30

Dalarna University 6 Tel: 023778800

Dalarna University 7 Tel: 023778800

The tasks of the project was to,

Dalarna University 8 Tel: 023778800

• Measure the baseline performance of static and real-time Asterisk on

1.4 Questions For Investigation

• How many simultaneous calls a single Asterisk can handle as a function of

• How many calls processed by static and real-time (Database) configuration.

Dalarna University 9 Tel: 023778800

• How big/fast the machine required for serving need.

1.5 Structure of Thesis

Dalarna University 10 Tel: 023778800

This thesis study involves the complete design of VoIP network,

The experiments were conducted for the interest of Cuuma Communications Oy in

To evaluate the performance of the Asterisk, many hardware and software

Dalarna University 11 Tel: 023778800

number of IP phones. It was impossible to connect 500 or more IP phones on LAN.

Dalarna University 12 Tel: 023778800

Fig 3-1, Proposed System Overview

To understand the functionality of the Asterisk, it is necessary to be aware of the

Dalarna University 13 Tel: 023778800

3.1 Circuit Switched Network

3.2 Packet Switched Network

Dalarna University 14 Tel: 023778800

3.3 Voice over IP

3.3.1 User Terminals

Dalarna University 15 Tel: 023778800

• To capture the proper degree of resolution, the voice information is sampled

• Each sample occupies 8 bits of data, so the overall bandwidth required is

3.3.3 Call Processing Server / IP PBX

Dalarna University 16 Tel: 023778800

3.3.4 Media / VoIP Gateway

Residential gateways provide traditional analog interface to the VoIP network.

Access media gateways provide a traditional analog or digital private branch

Dalarna University 17 Tel: 023778800

3.2.5 IP Network / Gatekeeper

4 Session Initiation Protocol (SIP)

Dalarna University 18 Tel: 023778800

4.1 SIP Distributed Architecture

Location Server Registrar Server Redirect Server

Figure 4-1, SIP Distributed Architecture

Dalarna University 19 Tel: 023778800

4.1.1 User Agents

Figure 4-2, Simplest communication between UAC and UAS

4.1.2 Proxy Server

Dalarna University 20 Tel: 023778800

In stateless servers, simple messages are straightly forwarded. The forward

INVITE INVITE UAS

UAS (FORKING) DECLINE