Lebanese French University

Faculty of Business Management

Bachelor in Computer Business / Networking Dept.

This graduation project is submitted for the degree of Bachelor in

Computer Business

Voice over Internet Protocols

(VoIP)

By

Student name: Ahmed AbdulSattar Younis

Student Number : 37

Supervisor name: Mr. Rawad Abikhalil

Internship Company: Gulfkeystone Petroleum

Internship Tutor: Mr. Ali Husain Ibraheem

Academic year (2010-2011)

BACHELOR in Business Computer Studies

BA MIAGE Graduation Project (GP)

INTERNSHIP FEASIBILITY APPROVAL REQUEST

Student full Name & Number: Ahmed Abdulsattar Younis

Student signature:

Student Information: Business computer \ Networking Dept.

Full name: Ahmed Abdulsattar Younis

Student number: 37

Student Address: Iraq – Erbil \ Minara

Internship/work company information :

Company name: Gulf Keystone Petroleum International Ltd

Company Address: 3rd Floor, UB Centre, Bakhtyari, Erbil, Kurdistan Region of Iraq

Company Activities: Oil development and Exploration.

Company Representative (internship agreement ) :

Full name: Hussein Dizzaye

Tel: +964 (0) 750 445 4542

Email: hdizzaye@gulfkeystone.com

Tutor:Company

Full name: Ali Husain Ibraheem

Tel: +964 (0) 750 330 5390

Email: aibraheem@gulfkeystone.com

Acknowledgement

We express my sincere thanks and appreciation to my supervisor (Mr. Rawad Abikhalil ) for his advice, support and guidance.

We would also like to thank all my family and friends for all their

support, time and encouragement, which helped us a lot all the way long.

Dedication

To My Family,

To My Country,

To My Supervisor,

To My Friends,

To My Department,

To My University,

To whoever interested in Persuasion,

I dedicate this Project.

4.1.1 Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.2 SIPp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.3 CPU RAM Analysis . . . . . . . . . . . . . . . . . . . . . 21 4.1.4 Shell Script . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 How to Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Contents

1 Introduction 1

1.1 General View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problem and Motivation . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Simulation Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 State of the Art 3

2.1 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 IP Telephone . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.3 VoIP Server . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.4 VoIP Gateway . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5 VoIP Protocols . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.6 PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.7 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Simulation Types . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Metrics and Parameters to be reported . . . . . . . . . . . 14 2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 SIPstone - Benchmarking SIP Server Performance . . . . 15

3 Specification 19

3.1 Server(Asterisk) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Simulate(SIPp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Design 20

4.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Implementation 23

5.1 Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.2 Asterisk Run Command . . . . . . . . . . . . . . . . . . . 24

5.2 SIPp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.1 User Agent Client(UAC) Scenario . . . . . . . . . . . . . 24

5.2.2 SIPp Run Command . . . . . . . . . . . . . . . . . . . . . 27

5.2.3 Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3 SAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.3.1 SAR Run Command . . . . . . . . . . . . . . . . . . . . . 30

5.3.2 Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3.3 CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3.4 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4 SHELL SCRIPT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Conclusion 35

6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2 Feature Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

References 36

List of Figures

1.1 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 VoIP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 ATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Linksys VoIP Router . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Soft Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 VoIP Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6 VoIP Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7 200 OK[3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.8 Registration test . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.9 Redirect test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.10 Proxy 200 test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 VoIP Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 Key1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2 Key2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3 Key3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.4 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.5 System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.6 Idle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.7 Memused . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.8 Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapter 1

Introduction

1.1 General View

Figure 1.1VoIP

Voice over Internet Protocol (VoIP) is a way to connect the voice conversations

over the network (Internet) or through any network using Internet Protocol and

therefore can be any number of people together online to a single network using

1

Internet Protocol to converse by telephone using the technique. The technology

converts analog audio signals from the phone an any audio once into digital

signals. This signal is divided into packets using Internet protocol and sent in

a number of digital tracks through the same data network. The arrival of these

packets to the specified destination (future) and the re-compilation of packets

sent to be heard clearly[1].

1.2 Problem and Motivation

Problem of pro ject voice when we want to test the performance of the VoIP

Quality of Service (QoS). Our Motivation is to provide solution this problem

by Simulation. Also, no previous project in LFU-BMU on treats VoIP.

1.3 Simulation Solution

The idea of Simulation is to simulate a real time application will a real VoIP

server and a set of connection (more). We use simulation because it is difficult

to bring 50 or more persons for test for performance of VoIP Quality of Service

(QoS).

2

Chapter 2

State of the Art

2.1 VoIP

Figure 2.1VoIP Operation

3

2.1.1 VoIP

History

The Institute of Electrical and Electronic Engineers (IEEE) published a pa-

per titled ”A Protocol for Packet Network Interconnection” in 1974 , VocalTec

released the first ever Internet VoIP program in 1995, ITU-T begins develop-

ment of standards for the transmission and signalling of voice communications

over Internet Protocol networks with the H.323 standard in 1996[1].

Applications

• VoIP in the Home:

It became possible to use the technology of VoIP at home, a number of

companies offer VoIP calling services that can be used in the home, more

or less replacing conventional PSTN service[3]. Some of these services

work only with proprietary telephone-calling software and don’t allow to

use a hard phone. Certain providers can support the use of a special

hard phone connected to PC’s USB port and uses the PC as a gateway

mechanism for accessing the network. Others provide an ATA device so

that can use one or more analog phones to receive calls using the service.

Still others offer the ability to use IP phones. VoIP enter in the home

quickly because of the license cost and the possibility of expansion and

proliferation of services such as: conference calls and the possibility to

install and preparation and control system[3].

• VoIP in Business:

Many vendors are producing cost-effective VoIP server devices for small

Ethernet LANs. These devices connect together endpoints in a small

office like a PBX, either through the use of conventional analog and dig-

ital phones (more on this later) or new-generation IP phones. In either

case, connecting calls to the PSTN and between local phones is usually

the responsibility of these server deviceslike a PBX or KTSand there are

several ways to make that PSTN connection. Using VoIP in small busi-

ness environments is easier when there’s some network savvy around the

office. Some traditional phone vendors are now implementing VoIP sys-

tems, so the availability of third-party networking expertise is accelerating

the adoption of VoIP in small businesses[3].

2.1.2 IP Telephone

Analog Telephone Adaptors(ATA)

The analog phone adapter ATA links any normal analog phone to the network

with Voice over Internet Protocol. This adapter has a port on the phone and

4

Figure 2.2ATA

Ethernet network port, ATA is a VoIP Gateways. VoIP at home or in business

does not need Internet access, a simple ATA would suffice[1].

VoIP Router

Figure 2.3Linksys VoIP Router

VoIP Router is connect two or more VoIP clients. A router also does frag-

mentation and reassembly with packets. Another function of a VOIP Router,

just like the name suggests, is to route the various packets into their destina-

tions. that a VOIP router communicates with the other VOIP routers on the

internet. VoIP at home or in business without any analog device needs internet

access. In this case a router is needed[1].

Soft Phone

Figure 2.4Soft Phone

A softphone is a software that emulate regular VoIP phone. This program

does not require more than provide a sound card and speakers and a micro-

phone. It provide a lot of service such as calling, answering and forwarding

cells. Examples: Net2Phone, PC2Call[1].

5

Figure 2.5VoIP Phone

VoIP Phone

Equipment is specially designed for this purpose is linked with a VoIP network

directly and does not need any additional equipment, such as ATA and did not

need to download any programs. These phones operate in accordance with

Internet protocol and one or more. Example: SIP Phone.

2.1.3 VoIP Server

VoIP Server turns an ordinary computer into a voice communications server.

VoIP server is no more than an existence computer with some programs also do

not need additional resources.

PBX

A private branch exchange (PBX) is a telephone exchange that serves a par-

ticular business or office. PBXs make connections among the internal telephones

of business company and also connect them to the public switched telephone

network (PSTN) via trunk lines.

Asterisk

Asterisk is the world’s most popular open source telephony project. Under

development since 1999, Asterisk is free, open source software that turns an

ordinary computer into a feature-rich voice communications server. Asterisk

makes it simple to create and deploy a wide range of telephony applications and

services. Code for Asterisk, originally written by Mark Spencer of Digium, Inc.,

has been contributed from open source software engineers around the world.

Currently boasting over two million users, Asterisk supports a wide range of

telephony protocols. It includes rich support for the handling and transmission

of voice over traditional telephony interfaces including analog lines, ISDN-BRI

lines and digital T1/E1 trunks. Asterisk also features support for a wide range

of VoIP protocols including SIP, IAX and H.323 among others. It supports

U.S. and European standard signaling types used in business phone systems.It

runs on Linux, Mac OS X, OpenBSD, FreeBSD and Sun Solaris. Asterisk can

be configured as the core of an IP or hybrid PBX (Private Branch Exchange),

switching calls, managing routes, enabling features, and connecting callers with

the outside world over IP[6].

6

Asterisk is like an erector set or a box of Legos for people who want to create

communications applications. That’s why we refer to it as a ”tool-kit” or ”de-

velopment platform”. Asterisk includes all the building blocks needed to create

a PBX system or virtually any other kind of communications solution. Some of

the blocks in the kit include:

• Drivers for various VoIP protocols.

• Drivers for PSTN interface cards and devices.

• Routing and call handling for incoming calls.

• Outbound call generation and routing.

• Protocol conversion (conversion from one protocol to another).

• Database integration for accessing information on relational databases.

• Web services integration for accessing data using standard internet proto-

cols.

This combination of components allows an integrator or developer to quickly

create voice-enabled applications. The open nature of Asterisk means that there

is no fixed limit on what it can be made to do. Asterisk integrators have built

everything from very small IP PBX systems to massive carrier media servers.

2.1.4 VoIP Gateway

Figure 2.6VoIP Gateway

A VoIP Gateway is a network device which convert voice calls between an IP

network and Public Switched Telephone Network (PSTN). There are two ways

VoIP gateways are used. First way is to convert incoming PSTN/telephone lines

to VoIP/VoIP telephone.the second way is to connect private branch exchange

(PBX)/Phone system to the IP network. The main functions of VoIP gateways

include voice compression or decompression, control signaling and call routing.

VoIP gateways cans also with additional features such as interfaces to external

controllers like Gatekeepers or Soft-switches and network management systems.

7

2.1.5 VoIP Protocols

A signalling protocol is a common language spoken by telephones and call-

management servers, the PSTN, and legacy PBX systems as they communicate

to set up, monitor, and tear down calls[2].

H.323 Protocol

H.323, currently in Version 2, is the ITU-T’s recommendation for PBX-styled

signaling that supports a packet-based network. H.323 was originally proposed

as a solution for video conferencing using LANs. Later revisions saw it morph

into a full-fledged PBX-replacement plan. H.323 is implemented in Microsoft’s

NetMeeting conferencing software, as well as in Avaya’s MultiVantage and Nor-

tel’s Meridian IP-PBX systems. Most integrators who choose this standard

tend to choose a single vendor’s implementation across their entire network.

Incompatibility of H.323 implementations is a problem only when trying to link

opposing vendors’ H.323 systems together[3].

H.323 message packets are compact, and H.323 signaling is very fast, es-

pecially compared to SIP, which uses comparatively long and wordy message

packets. The design of H.323 is very much rooted in the design philosophy of

the PSTN: brevity and availability are striven. H.323 signals are short. The net-

work is used as little as possible to carry call signaling and as much as possible

to carry sound. The gatekeeper is the host on the network that provides cen-

tralized call monitoring and signaling capabilities for H.323 endpoints (called

terminals). It is common to refer to an H.323 gatekeeper as a softswitch or

softPBX[3].

IAX Protocol

The Inter-Asterisk Exchange Protocol (IAX), currently in its second revision.

The chief difference between IAX and the other signaling families is that IAX

doesn’t implement RTP as the packetizing mechanism. Instead, IAX has its

own way of packaging encoded voice.IAX is also (Network Address Translation)

NAT-proof, hundreds of simultaneous calls from behind a masquerading firewall

will function correctly, just as HTTP does[3].

IAX is implemented in a far-simpler and less application-exhaustive manner

than SIP and H.323. It is really intended just for telephony applications, while

H.323 and especially SIP, include far more extensibility. IAX is therefore much

more compact; complete implementations have been done with as little as 64

kb of ob ject code. Unlike SIP and H.323, IAX is not a standards recommenda-

tion, but rather an independent protocol created by Mark Spencer, founder of

Digium[3].

8

SIP Protocol

The Session Initiation Protocol (SIP) was developed by the Internet Engineer-

ing Task Force (IETF) as a way of signaling multiuser distributed telephony and

messaging applications on an IP network.SIP has garnered much praise from IT

professionals, while suffering some criticism from traditional telecommunica-

tions people. The main reason for its less-than-perfect repute with telecom pros

is its origin outside the telecom world. But many telecom guys have had to for-

give this, because they’re learning that SIP has almost no shortcomings when

compared to its ITU-inspired cousin[3].

The essential duties and formulaic pieces of SIP are the same as H.323. There

are VoIP endpoints of varying capabilities, and there are servers that participate

in the signaling process and establish policy for the voice network. Unlike H.323,

however, SIP is far more extensible. It is more than just a set of voice and

video telephony protocols. Rather, it’s a packaging framework for all types of

message-based applications, from intercom calling to instant messaging and AV

services[3].

Avaya, Cisco, Siemens, Alcatel, and the major telephony hardware vendors

have indicated a strong support attitude about SIP, while some have even backed

away from H.323 investments. This bodes well for SIP’s future, and there are

already more SIP IP phones installed worldwide than there are H.323 ones. SIP

uses readable headers like SMTP or HTTP. SIP is currently in Version 2.0. Its

definition is found in RFCs 3261 through 3265[3].

• SIP Nodes

SIP endpoints and servers are called nodes. A SIP phone is a node. SIP

phones can communicate directly with each other in order to establish

media sessions, just as H.323 terminals can establish direct channels. But

more often than not, especially in an enterprise setting, SIP is used with

a SIP server. SIP phones normally report to a dedicated SIP server node

called a registrar upon boot-up[3].

• SIP Registrar

The SIP registrar is a database server that communicates with SIP

nodes in order to collect, store, and disperse information about the where-

abouts of SIP users. When a SIP node registers with a registrar, it tells

that registrar how to get hold of the user, specifically what IP address

and port to use for future SIP communication. You could think of the

registrar as a router, because its main purpose is to give advice on how to

reach SIP users, just as a TCP/IP router’s purpose is to give advice on

how to reach other networks[3].

• URIs

9

SIP endpoints can be referenced using Uniform Resource Indicators, but

so can SIP users. Consider this URI:

sip:lerxt@sip.bytor.com

This convention indicates both the user to be contacted and the server

that is expected to know the address of that user’s SIP endpoint. In this

case, the user is lerxt and the server is sip.bytor.com[3].

• SIP Methods and Responses

SIP signals fall into 10 categories called methods. Each method accom-

plishes a different function for SIP:

– INVITE: This method is used to start sessions and advertise endpoint

capabilities.

– ACK: This method is used to acknowledge to the called SIP peer

that an INVITE has succeeded.

– BYE: This method occurs when the call is completed, that is, one

user at a minimum wishes to end the call.

– CANCEL: This method is used during attempts to override a prior

request that hasn’t yet been completed.

– OPTIONS: This method is used to query a SIP peer for its capabil-

ities information, without actually establishing a media channel.

– REGISTER: This method notifies the SIP server at which endpoints

a particular user can be reached.

– INFO: This method is used to transmit telephony application sig-

nals through the SIP signaling path; these signals can include dialed

digits.

– PRACK: This method (Provisional ACK) is used to notify an end-

point of intent to set up a complex call without actually providing

an ACK. PRACK is the SIP equivalent of ”all is well.”

– SUBSCRIBE: This method provides a way of establishing event han-

dlers within SIP telephony applicationsi.e., ”Tell me when Bob misses

a call” or ”Tell Bob when I am registered with the server.”

– NOTIFY: This method delivers messages between endpoints as events

occuri.e., ”Bob missed a call.”

When a call must be started, ended, or altered, a SIP method is employed.

The SIP methods in the preceding list are similar in concept to the HTTP

methods GET and POST, and like HTTP, SIP expects response codes

when it sends a method.

In Figure 2.7, you can see that a (highly simplified) call from an Internet

host (A), in the form of a SIP INVITE, to 5150@oreilly.com, would ordi-

narily result in a 200 OK response, clearing the way for the call to begin.

• SIP Proxies

10

Figure 2.7200 OK[3]

A SIP proxy is a server that routes or redirects SIP INVITE methods

on behalf of one or more domains, just as a web server provides responses

to HTTP methods for certain domains. So, when an incoming call from

a foreign network is recognized, the SIP proxy’s job is to connect it to

the called user’s endpoint, if possible. Outbound SIP proxies serve the

task of connecting calls, but on behalf of a local network of SIP users.

Many users may share the same SIP proxy because they work in the same

office or perhaps because they subscribe to the same SIP dial-tone ser-

vice provider. Outbound SIP proxies are often used to overcome network

communications problems posed by NAT firewalls. Some local calls may

benefit from being routed through a SIP proxy, too. Forcing even local SIP

endpoints to use a SIP proxy allows for easy enforcement of a dial-plan,

greater administrative control over the voice network, and the ability to

do centralized telephony applications such as call recording[3].

• SIP User Agent Elements

All SIP proxies and endpoints are comprised of two key software ele-

ments, the user agent client and user agent server (UAC and UAS).

All SIP devicesbe they softphones, hardphones, voice mail servers, or

full- blown PBX servers must be able to speak the SIP protocol, and the

UAC and UAS elements are their mouthpieces. The UAC sends methods

and receives responses, so its logical equivalent in HTTP is the web

browser. The UAS receives SIP methods, processes them, and returns

responses, so it’s more like a web server. In varying degrees of

completeness, all SIP endpoints and servers have both a UAC and a

UAS[3].

• SIP redirect

11

When a SIP server responds to a calling endpoint’s INVITE method

with a 3xx response, that SIP server is redirecting the calling endpoint

to a different SIP server. The calling endpoint should then contact that

server with an INVITE method for further assistance in connecting the

media stream. This feature is not implemented on all systems that support

SIP. In fact, where complex, signaling-neutral dial-plan programming is

available (like in Asterisk), SIP redirection isn’t always necessary. The use

of SIP redirects is more common in large, SIP-only networks with multiple

servers, such as those that span the Internet[3].

• Real-Time Streaming Protocol

Unlike H.323, the SIP protocol family provides a built-in recommen-

dation for streaming prerecorded audio and video, in this case the RTSP

protocol. This is the same protocol used by RealOne and similar media

player applications. It’s defined by RFC 2326[3].

H.323 vs SIP vs IAX

H.323 SIP IAX Standards body ITU-T IETF Digium, Inc.

Architecture Distributed Distributed, Peer-to-Peer Distributed Built-in legacy

device support

recommended

Yes, via gateways No recommended No

Signalling Transport TCP/UDP TCP/UDP UDP Multimedia Telephony, video Telephony, instant messaging, video Telephony

SoftPBX call path is called a... Gatekeeper-routed Proxy SoftPBX Messaging approach ISDN-like HTTP-like Proprietary

Table 2.1Comparison between H.323 and SIP and IAX[2][3]

Conclusion

H.323 is older than SIP, more considerate of legacy infrastructure, and con-

tains many applications, but H.323 is more complex reverse SIP application

and be easy to understand and not complicated. One big advantage of SIP

is its comfort in non-telephony applications, such as instant messaging, video,

and white-boarding. Apple’s iChat and Microsoft’s MSN Messenger use SIP

for these purposes. Earthlink’s SIPShare application allows peer-to-peer media

sharing using SIP. Extensibility is an appealing characteristic of SIP. Lack of

extensibility is the drawback of H.323. Our project depends on the SIP protocol

to communicate through the Internet Protocol.

12

2.1.6 PSTN

The public switched telephone network (PSTN) is the network of the world’s

public circuit-switched telephone networks. The network that connects all these

phones together wraps around the globe. The job of the PSTN (Public Switched

Telephone Network) is to reliably facilitate telephone conversations at any time

of day, year-round. The PSTN combines analog, digital, and electromechanical

data links. There are also private networks run by large companies which are

linked to the PSTN only through limited gateways, like a large private branch

exchange (PBX)[5].

2.1.7 GSM

Global System for Mobile communications (GSM) is the most popular stan-

dard for mobile phones in the world. GSM is used by over 3 billion people

across more than 212 countries. GSM is considered a second generation (2G)

mobile phone system, GSM EDGE is a 3G version of the protocol. Today’s

GSM platform is living, growing and evolving and already offers an expanded

and feature-rich ’family’ of voice and multimedia services[2].

2.2 Simulation

VoIP simulation try to provide a mirror image of what might be a VoIP

architecture in the real world. The objective of the simulation is the study of

VoIP and build models of VoIP architecture. It also tests the quality of service

offered to people so there is no flaws in the use of VoIP, and study the Latency,

Jitter, Errors Rate and Availability. For example of VoIP Simulation: SIPstone

is a benchmark for SIP (Session Initiation Protocol) proxy and redirect Servers

(SIP Server).

2.2.1 Simulation Types

The Real Test

Real test of VoIP be several or more people are communicating to the server

in order to test the performance of communication through IP. This is costly

and also physically impossible to bring many people.

Pure Simulation

Pure Simulation is also called Network Simulation is based on mathematical

equations or events that occur in the network, and can also edit the different

environments. Simulation makes the client and the server and the result of their

work. There is one drawback is that simulation is not simulate the real world.

Examples of notable network simulation software are:

ns2/ns3 (Network Simulator), OPNET (Optimized Network Engineering Tools).

13

Semi-Simulation

Semi - Simulation of VoIP is Depends on a server with a specific program,

such as Asterisk, this program is making many clients are communicating to the

server. Simulations here are making real clients are communicating through the

Internet protocol to the server for the quality of the performance of VoIP. Our

project will be based on this simulation for making large numbers of clients.

2.2.2 Metrics and Parameters to be reported

When simulation an architecture, the following data has to be provided.

• Description of the clustering configuration, including the number of hosts

and the load balancing mechanism used.

• All aspects of the server hardware.

• The server operating system and version and any non-standard tunings or

settings.

• The server software configuration.

• The number and type of load generators that participate in the run.

• The number and type of network segments connecting the load generators

to the SIP server.

• The arrangement of load generators on the network segments.

• The workload parameters except the load level.

To remove one variable from the measurement results, the server and

load generators should be connected by a switched 100Mb/s Ethernet that

only carries measurement-related traffic and no other LAN traffic.

• The number of connections requested by the clients and accepted by the

Server Under Test SUT per second;

• CPU and memory utilization of server at various loads;

• A curve plotting the Transaction Response Time (TRT) as a function of

request arrival rates;

• Calls per second (CPS) and Registrations per second (RPS);

14

2.3 Related Work

Pro jects of VoIP Simulation are few, we will also talk about one pro ject, it is

SIPstone. It is also regarded as standard. We will talk about how it was started

and the methods it used for getting the results and environments that use the

VoIP. Our simulation will use it to get advanced results in the VoIP parameters

to improve the performance of VoIP.

2.3.1 SIPstone - Benchmarking SIP Server Performance

SIPstone is designed by Henning Schulzrinne, Sankaran Narayanan, Jonathan

Lennox and Michael Doyle[4]. This section proposes an initial simple set of met-

rics for evaluating and benchmarking the performance of SIP proxy, redirect and

registrar servers. SIPstone is a benchmark for SIP (Session Initiation Protocol)

proxy and redirect Servers (SIP Server). SIPstone is designed to be a bench-

mark with a single standardized implementation and workload. The implemen-

tation performs a series of tests that generate the pre-configured workload. This

workload is performed in a controlled IP telephony test bed that simulates the

activities of multiple users initiating SIP calls. The benchmark currently is lim-

ited to evaluating the sustainable rate of what we believe to be a representative

workload, consisting of registrations, successful forwarding and unsuccessful call

attempts[4].

SIP supports user mobility by allowing addresses in the form of user@domain

to be used when making Internet calls. For instance, alice@home.com can call

bob@office.com no matter what communication device, IP address or phone

number bob is using currently. The locations where users could be reached are

maintained by the SIP location or registration servers. The performance of a

SIP server depends not only on the implementation but also the size of the

user population serviced, the number of DNS lookups required, the transport

protocol used (UDP or TCP), and the type and statistical arrival process of

requests submitted[4].

SIPstone describes a workload for SIP requests in proxies using a set of tests

that exercise various components of typical SIP servers.

Architecture

The ”server under test” (SUT) is a SIP proxy, redirect or registrar server

whose performance is to be estimated. The benchmark consists of a set of

SIPstone load generators that create the SIP request load, a call handler that

simulates a user agent server (UAS) and a central benchmark manager (”coor-

dinator”) that coordinates the execution of the benchmark, and the SUT. The

call handlers may run along with the load generators or on different systems[4].

15

Description of Tests

The benchmark currently consists of five tests. Each test is performed using

both UDP and TCP, with results reported separately for each transport proto-

col. Thus, a total of ten results is to be reported for servers that support both

transport protocols[4]. The individual tests are:

• Registration

The transaction delay is measured from sending the first REGISTER re-

quest to receiving the final 200 response, including the 401 ”Unauthorized”

message.

Figure 2.8Registration test

• Outbound proxy

The load generator sends an INVITE request to the SUT acting as an

outbound proxy. The message flow is the same as for the ”Proxy 200”

test below[4].

• Redirect

The load generator sends an INVITE request to the SUT acting as a

redirect server. It is assumed that all call destinations have registered

with that server. The transaction delay is measured from sending the

INVITE request to receiving the 3xx response[4].

• Proxy 480

The load generator sends an INVITE request to the SUT acting as a

redirect server. The call destinations are known to the server, but have

16

Figure 2.9Redirect test

not registered, so that the server returns a 480 (Temporarily unavailable)

response. The request is not authenticated.

• Proxy 200

The load generator alternates between INVITE and BYE transactions to

the SUT acting as a non-forking proxy server. The BYE transaction is

sent immediately after the INVITE transaction completes. The requests

are not authenticated. The server should insert a Record-Route to reflect

real operational conditions, however, the operation of the system does not

depend on this since the caller load generator always sends the request to

the SUT.

17

Figure 2.10Proxy 200 test

18

Chapter 3

Specification

3.1 Server(Asterisk)

In our project, we need a server for receiving a large number of callers each

one can listen to the answering machine for a certain period. For that we will

need to Asterisk server, which can provide the Interactive Voice Response(IVR)

system can receive large numbers of callers.

3.2 Simulate(SIPp)

The real tests in VoIP, to meet a large number of callers each one with a

computer and then call to the server at the same time in order to improve the

performance of communication and knowledge of its shortcomings. And this

is very expensive and also impossible to collect large numbers of callers. We

will need to SIPp which is doing the same test simulation of the real and also

generates a large number of distributors such as: 100.100000,..etc. And also we

can control the connection process, such as: increasing the number of callers

every 5 seconds and other complex scenarios.

19

Chapter 4

Design

In VoIP Simulation project design is on two stages , the first stage is on tools

there are available for do this project, the anther stage is how work this pro ject

means what happen in inside this pro ject.

4.1 Tools

We must have 4 tools for design the pro ject:

4.1.1 Asterisk

The first stage in design for VoIP Simulation is in Asterisk server, so we start

in build Asterisk server. Two ways in build Asterisk server. First way we can

Installing Asterisk by go to Synaptic Package Manager then write asterisk and

install packages. Second way is write command: apt-get install (name package),

in terminal Linux. The Asterisk version is 1.6. Finally we can run asterisk by

[asterisk -R].

4.1.2 SIPp

The second stage in design is clients which clients call to server. SIPp can

generation clients and can call to Asterisk server, so in build SIPp is two ways

are the same as build in Asterisk server. Pre-requisites to compile SIPp are:

• gcc-c++: C++ Compiler.

• ncurses-devel: curses or ncurses library.

20

• openssl-devel and libssl-dev: For authentication and TLS support: OpenSSL

= 0.9.8.

• libpcap 0.8 and libnet: For pcap play support.

For install SIPp go to Synaptic Package Manager then write sip-tester(SIPp)

and install it. Now we can start SIPp and call to Asterisk server for VoIP

Simulation.

4.1.3 CPU RAM Analysis

The third stage is use System Activity Reporter(SAR) tool can measure CPU

and RAM state when clients call to server. In the build stage is the same as

tools in the above. the important SAR packages:

• debconf (0.5): Debian configuration management system.

• libc6 (2.3.4-1) : GNU C Library: Shared libraries and Timezone data also

a virtual package provided by libc6-udeb.

• dep: lsb-base (3.0-6) : Linux Standard Base 3.1 init script functionality.

• dep: ucf (2.003) : Update Configuration File: preserves user changes to

config files.

Now we can start in measure CPU and RAM state and wait for results.

4.1.4 Shell Script

The final stage is how method to run project in a particular case. We use

’sh’ shell script because we can run the tools in the same time, then extract

the results then put them in file for we can study the results and know how to

improve them.

4.2 How to Work

Here we will describe or explain what happen in the project, so we design the

project by Flow Chart even be a simple way to understand the pro ject.

21

Figure 4.1VoIP Design

22

Chapter 5

Implementation

The idea of the project is first run asterisk for receive calls from users ,then

run SAR for CPU and RAM analysis, then run SIPp for generate the users,

then put the results from analysis to file for use in curve.

5.1 Asterisk

5.1.1 Configuration

The Asterisk configuration files for a standard install in the /etc/asterisk

directory:

sip.conf

In the /etc/asterisk/sip.conf file we can configure everything related with the

SIP protocol, add new sip users or define sip providers.

[ s i p p ] t y p e= f

r i e n d c o n t e x

t=s i p p h o s t=d

y n a m i c p o r t

=6000 u s e r=s i

p p

c a n r e i n v i t e =no

d i s a l l o w = a l l a l l

o w=u l a w

The [sipp] section defines parameters for the sipp SIP extension. The parame-

ter type=friend simply means that this SIP extension can both accept and make

calls[11]. We are calling the context sipp in /etc/asterisk/extensions.conf; When

we look at that file in the next section, the application of contexts should become

clearer[11]. The term host=dynamic tells Asterisk that it doesn’t matter if the

23

IP address of the SIP extension sipp changes[11]. The port for SIP connections

is 6000. Then user=sipp: can only accept calls from sipp. Then Disallow all

codecs (global configuration). Finally allow codecs in order of preference.

Interactive Voice Response (IVR)

An interactive voice response system lets computer systems interact with tele-

phone callers, who provide input to the system either by pressing the keypad

on their telephone set or by saying something (natural language speech recog-

nition). Most IVR systems provide selection menus for routing calls without

requiring operator intervention, but modern IVR systems can also be very com-

plex applications that handle information or control equipment[10].

extensions.conf

The /etc/asterisk/extensions.conf – known as the (dialplan) – is the heart of

every Asterisk configuration. In a sense, we can equate them with a switch-

board used in early telephone systems. The dialplan determines which phones

can make calls to other phones, and how[11].

[ s i p p ]

e x t e n => 2 0 0 5 , 1 , Answer

e x t e n => 2 0 0 5 , 2 , S e t M u s i c O n H o l d ( d e f a u l t )

e x t e n => 2 0 0 5 , 3 , Wait M usic On Hold ( 2 0 ) e x t e

n => 2 0 0 5 , 4 , Hangup

The first section of the configuration is the context [sipp]. The caller dials ex-

tension 2005, Asterisk answers and plays default music then wait for 20 seconds

then close the call.

5.1.2 Asterisk Run Command

asterisk -R : This is show the Asterisk CLI (command line interface) which

lets us interactively control Asterisk, and also is important for run Asterisk

server. So we will start this command and after that we will stop this command

by core stop now.

asterisk -vvvvvc : This command run Asterisk server and display communi-

cation situations. asterisk : This command run Asterisk server in background.

5.2 SIPp

5.2.1 User Agent Client(UAC) Scenario

24

A s c e n a r i o w i l l a l w a y s s t a r t w i t h :

<?xml v e r s i o n = ” 1 . 0 ” e n c o d i n g =”ISO −8859−1”?>

<!DOCTYPE s c e n a r i o SYSTEM ” s i p p . d t d ”>

< s c e n a r i o name=” u a c 3 ”>

And end with:

</ s c e n a r i o >

<s e n d r e t r a n s =”500”>

I n i t i a t e t i m e r t o 5 0 0 m i l l i s e c o n d s when t h e m e s s a g e i s s e n t .

And end w i t h :

</s e n d >

Inside the ”send” command, you have to enclose your SIP message between

the ”[CDATA” and the ”]]” tags. Everything between those tags is going to be

sent toward the remote system. Those keywords in the SIP message are used

to indicate to SIPp that it has to do something with it.[7]

INVITE s i p : [ s e r v i c e ] @ [ r e m o t e i p ] : [ r e m o t e p o r t ] SIP / 2 . 0

Here the INVITE message is sent service name, IP address and port.

V i a : SIP / 2 . 0 / [ t r a n s p o r t ] [ l o c a l i p ] : [ l o c a l p o r t ] ; b r a n c h =[ b r a n c h ]

The message is sent through protocol SIP, transport UDP, host IP address, port

chosen by the system and Provide a branch value is a concatenation of cookie

+ call number + message index.

From : s i p p < s i p : s i p p @ [ l o c a l i p ] : [ l o c a l p o r t ] > ; t a g =[ c a l l n u m b e r ]

The message is sent from caller number.

To : s u t < s i p : [ s e r v i c e ] @ [ r e m o t e i p ] : [ r e m o t e p o r t ] >

The message is sent to service.

C a l l −ID : [ c a l l i d ]

Caller ID.

CSeq: 1 INVITE Generates automatically the CSeq number.

25

C o n t a c t : s i p : s i p p @ [ l o c a l i p ] : [ l o c a l p o r t ]

Here contact host IP address with port.

Content-Length: [len]

Computed length of the SIP body.

v=0

o=u s e r 1 5 3 6 5 5 7 6 5 2 3 5 3 6 8 7 6 3 7 IN I P [ l o c a l i p t y p e ] [ l o c a l i p ]

s=−

c=IN I P [ m e d i a i p t y p e ] [ m e d i a i p ]

t =0 0

m=a u d i o [ m e d i a p o r t ] RTP/AVP 0

a=r t p m a p : 0 PCMU/ 8 0 0 0

Here is owner name, service name, system name, type IP address, local IP

address for RTP echo. Depending on the values of parameters.

Now that the INVITE message is sent, SIPp can wait for an answer by using

the ”recv” command.

<r e c v r e s p o n s e =”100”> o p t i o n a l =” t r u e ”

</ r e c v >

<r e c v r e s p o n s e =”180”> o p t i o n a l =” t r u e ”

</ r e c v >

The 100 and 180 SIP messages can be received without being considered as

”unexpected”.

<r e c v r e s p o n s e =”200” r t d =” t r u e ”>

</ r e c v >

Record Route Set. if this attribute is set to ”true”, then the ”Record-Route:”

header of the message received is stored and can be recalled using the[routes]

keyword.[7]

100 and 180 messages are optional, and 200 is mandatory. In a ”recv” se-

quence, there must be one mandatory message.[7]

Then send the ACK, in send the ACK is almost the same as INVITE.

26

<s e n d >

< ! [CDATA[

ACK s i p : [ s e r v i c e ] @ [ r e m o t e i p ] : [ r e m o t e p o r t ] SIP / 2 . 0

.

.

] ] >

</s e n d >

Then the scenario will wait for time is write in parameter -d.

<p a u s e />

And finish the call by sending a BYE and expecting the 200 OK:

<s e n d r e t r a n s =”500”>

< ! [CDATA[

BYE s i p : [ s e r v i c e ] @ [ r e m o t e i p ] : [ r e m o t e p o r t ] SIP / 2 . 0

.

.

] ] >

</s e n d >

<r e c v r e s p o n s e =”200” c r l f =” t r u e ”>

</ r e c v >

Displays an empty line after the arrow for the message in main SIPp screen.

<R e s p o n s e T i m e R e p a r t i t i o n v a l u e = ” 1 0 , 2 0 , 3 0 , 4 0 , 5 0 , 1 0 0 , 1 5 0 , 200”/ >

response time values are distributed between 0 and 10ms, 10 and 20ms, 20 and

30ms,...etc.

<C a l l L e n g t h R e p a r t i t i o n v a l u e = ” 1 0 , 5 0 , 1 0 0 , 5 0 0 , 1 0 0 0 , 5 0 0 0 , 10 000 ”/ >

call length values are distributed between 0 and 10ms, 10 and 20ms, 20 and

30ms,...etc.

5.2.2 SIPp Run Command

s i p p − s f u a c 3 . xml − s 2 0 0 5 1 2 7 . 0 . 0 . 1 −d 5 0 0 0 −m 3 0 0 − l 3 0 0 −t r a c e m s g

− t r a c e s c r e e n − t r a c e s t a t − t r a c e e r r

27

• -sf: Loads an alternate xml scenario uac3.xml.

• -s : service name 2005.

• 127.0.0.1 : IP address.

• -d 5000 : Pause traffic, the scenario will wait for 5 second[12].

• -m 300 : Stop the test and exit when ’300’ calls are processed[12].

• -l 300 : Set the maximum number of simultaneous calls. Once this limit is

reached, traffic is decreased until the number of open call goes down[12].

• -trace msg : Displays sent and received SIP messages in scenario file name

ppid messages.log[12].

• -trace screen : Dump statistic screens in the scenario name ppid screens.log

file when quitting SIPp[12].

• -trace stat : Dumps all statistics in scenario name ppid.csv[12].

• -trace err : Trace all unexpected messages in scenario file name ppid er-

rors.log[12].

5.2.3 Screens

Several screens are available to monitor SIP traffic. You can change the screen

view by pressing 1 to 9 keys on the keyboard. In the project is three screens is

available:[7]

Key ’1’: Scenario screen. It displays a call flow of the scenario as well as some

important informations.[7]

Figure 5.1Key1

28

Key ’2’: Statistics screen. It displays the main statistics counters. The ”Cu-

mulative” column gather all statistics, since SIPp has been launched. The ”Pe-

riodic” column gives the statistic value for the period considered (specified by

-f frequency command line parameter).[7]

Figure 5.2Key2

Key ’3’: Repartition screen. It displays the distribution of response time and

call length, as specified in the scenario.[7]

Figure 5.3Key3

5.3 SAR

SAR is the System Activity Reporter. By interpreting the reports that SAR

produces, you can locate system bottlenecks and suggest some possible solutions

to those annoying performance problems. The Linux kernel maintains internal

counters that keep track of requests, completion times, I/O block counts, etc.

From this and other information, SAR calculates rates and ratios that give

insight into where the bottlenecks are[8]. And anther thing is System activity

29

data formatter(sadf ) extracts data in a format that can be easily ingested by a

relational database.

5.3.1 SAR Run Command

s a r −u −o s t r e s s 1 . s a r 1 1 8 4

−u : F o r CPU s t a t e , −o : s o r t e d r e s u l t s on f o r m b i n a r y i n f i l e ’ s t r e s s 1 . s a r ’

, 1 : D i s p l a y CPU s t a t e i n e a c h 1 s e c o n d , 1 8 4 : D i s p l a y 1 8 4 t i m e s o f CPU s t a t e .

s a r −r −o s t r e s s 2 . s a r 1 1 8 4

− r : F o r RAM s t a t e .

5.3.2 Screens

5.3.3 CPU

The %user and %system columns simply specify the amount of time the

CPU spends in user and system mode. The %iowait and %idle columns are of

interest to us when doing performance analysis. The %iowait column specifies

the amount of time the CPU spends waiting for I/O requests to complete. The

%idle column tells us how much useful work the CPU is doing. A %idle time

near zero indicates a CPU bottleneck, while a high %iowait value indicates

unsatisfactory disk performance.[8]

5.3.4 RAM

fields show the typical free and used memory statistics, with the percentage

of memory used displayed in the %memused field. The kbbuffers and kbcached

fields show how many kilobytes of memory are allocated to buffers and the

system-wide data cache. For swap utilization, the kbswpfree and kbswpused

fields show the amount of free and used swap space, in kilobytes, with the

%swpused field showing the swap space used as a percentage. commit is the

amount of physical memory (RAM) and virtual memory that is allocated to

all running programs, or applications, and the operating system itself. The

commit will increase when applications are opened and used and decrease when

applications are closed.[9]

5.4 SHELL SCRIPT

I used shell script for I can run several command in the same time and the

simulation and the analysis are stopped in the same time. The file name is

’script2.sh’.

30

#!/ b i n / s h

gnome−t e r m i n a l −e ’ s a r −u −o s t r e s s 1 . s a r 1 1 8 4 ’

gnome−t e r m i n a l −e ’ s a r −r −o s t r e s s 2 . s a r 1 1 8 4 ’

Firstly We run tow terminal are SAR command: first is for CPU performance

-u and anther is for RAM performance. The analysis is in each 1s and number

of analysis is 184 lines. then the results is stress1.sar by -o.

a =10

w h i l e [ \ $ a − l e 3 0 0 ]

do

s i p p − s f u a c 3 . xml − s 2 0 0 5 1 2 7 . 0 . 0 . 1 −d 5 0 0 0 − r \ $ a −m \ $ a − l \ $ a

−t r a c e m s g − t r a c e s c r e e n − t r a c e s t a t − t r a c e e r r

a=\$ ( ( a + 1 0 ) )

d o n e

Secondly we use loop for in each call increase by 10 callers then stop the

communication at 300 callers. we use SIPp command for generation users then

they calls to name server in Asterisk 2005 in address 127.0.0.1, and pause or

duration is 5s, and -r is number of callers, and -m is the final call, and -l is the

limit. All -r, -m and -l are the same variable a.

s a d f −d s t r e s s 1 . s a r −− −u > s t r e s s 1 . c s v s a

d f −d s t r e s s 2 . s a r −− −r > s t r e s s 2 . c s v s e d

’ s / ; / / g ’ s t r e s s 1 . c s v > s t r e s s 1 1 . c s v s e d

’ s / ; / / g ’ s t r e s s 2 . c s v > s t r e s s 2 2 . c s v

Finally sadf is doing conversion binary file to file we can read the results for

CPU and RAM. Then sed is doing conversion ” ”tospacef orwecanuseinchart.

5.5 Performance Analysis

Here is the result from all the pro ject work, we take informations from CPU

and RAM utilization by SAR and is on form Chart.

31

Figure 5.4User

Figure 5.5System

32

Figure 5.6Idle

Figure 5.7Memused

33

Figure 5.8Commit

34

Chapter 6

Conclusion

In conclusion, I learned a lot from VoIP Simulation through information,

tools and applications. And also learned how to complete the work by writing

reports, and implementation of the pro ject several times. I also faced difficulties

during the writing and implementation of the pro ject, and I also want to make

the project, particularly through the IVR system to be where a large database

and listen to more than one voice. In general, VoIP technology revolution has

become a large used everywhere because of the benefits of more of the benefits

of regular communications, and also most of the applications and tests on VoIP.

6.1 Summary

First, we talked about the general problem of VoIP, and also we talked about

Motivations and solutions. Then we talked about the state of the art of VoIP

describe each part of VoIP operation, also about types of simulation and Pa-

rameters to be reported. Then we talked about related work and simulation

that is we chosen, that is SIPstone. Then we talked about specification and

design for VoIP Simulation. Then finally we talked about implementation and

performance analysis of VoIP Simulation.

6.2 Feature Work

In feature works of VoIP Simulation are simulation and test are in the big

system specially in IVR system contain on database and more of sound file for

is the test very good, and also use Free PBX can call to server from any place.

35

References

1 http://en.wikipedia.org/wiki/Voice over Internet Protocol.

2 Implementation of VoIP System for Pilgrims in Al-Haj, Author: Zeyad A.

Al-Shaikh.

3 Switching to VoIP, Author: Theodore Wallingford, Publisher: O’Reilly.

4 SIPstone - Benchmarking SIP Server Performance, Authors: Henning

Schulzrinne, Sankaran Narayanan, Jonathan Lennox, Michael Doyle.

5 http://en.wikipedia.org/wiki/BSTN.

6 http://www.asterisk.org/asterisk.

7 http://sipp.sourceforge.net/doc3.0/reference.html

8 http://pagesperso-orange.fr/sebastien.godard/tutorial.html

9 http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/admin-primer/s1-

memory-rhlspec.html

10 http://www.the-asterisk-book.com/unstable/kapitel-ivr.html

11 http://www.the-asterisk-book.com/unstable/minimale-telefonanlage.html

12 http://sipx-wiki.calivia.com/index.php/Using SIPp to run performance tests

36