performance analysis of voice codec for voip

PERFORMANCE ANALYSIS OF VOICE CODEC FOR VOIP

ALI ABD. KHUTHER

A project report submitted in partial fulfillment of the

requirements for the award of the degree of

Master of Science (Computer Science)

Faculty of Computer Science & Information Systems

Universiti Teknologi Malaysia

OCTOBER 2008

III

Thank To My Lord, Allah,

My Parents And My Family Members,

My Related And All Friends.

IV

ACKNOWLEDGEMENT

“In the name of Allah, the most Beneficent, the most Merciful”

In preparing this project report, I was in contact with many people,

researchers, academicians and practitioners. They have contributed toward the

success, and given a moral support to accomplish this project. At the very beginning,

I would like to thank my beloved father and mother for every thing, and I ask Allah

the almighty to grant them the Paradise.

I wish to express my sincere appreciation to my supervisor, Dr. Md Asri Bin

Nagadi for guidance, critics and friendship. And the great advice which he always

used to gave me. I would like to thank Dr. Muhammad Shafie Abd. Latiff and Dr.

Norafida Bte Ithnin too for their meaningful comments which are lead to improve my

research skills.

Not to forget my fellow postgraduate students, my family member and all my

related I thank you sincerely and wish you the best, brighter success and blessedness

in your live. Also special thanks should go to Ms. Fadhlia Suhaili, for her moral

support and important contribution.

V

ABSTRACT

Recently, VoIP (Voice over Internet Protocol) is a great interesting voice

communication over the Internet, with high level quality of service (QoS) along with

circuit switch and cellular. The objective in this project is to assess to what extend

today’s internet in meeting this expectation via studying VoIP performance and its

QoS. However, the methodology in this project is, first the CODECs are selected by

some criteria then apply them on SIP server to finally come out with the result from

the simulation in order to make comparison and analysis the QoS. This work

implements VoIP protocols for two connected user using SIP server with its three

CODEC algorithms. After define the main problems in this area set of parameters are

taken into account due to their affection to the performance of the voice, such as

jitter, packet loss, packet delay and throughput. This project is simulated three

existing CODECs (converting the voice from analog to digital and compressing the

packets) using the most common CODECs with VoIP, they are G.711, G.723 and

G.729. However, the simulation will use NS2 platform with vary values of packet

size and number of calls. Finally, the main objective from this project is to obtain a

high quality of voice by make a proper decision for choosing the codec voice. As

conclusion, G.711 is a preferred technique when the quality is required because of

the high throughput from its packets, while G.723 perform well with the high

bandwidth means it can handle many user. Finally, G.729 the high level compression

is the proper technique for many user and heavy data only when the quality is not

taken into account.

VI

ABSTRAK

Belakangan ini, VoIP (Voice over Internet Protocol) adalah suatu komunikasi

suara melalui internet yang menakjubkan, dengan kualiti servis (Qos) pada tahap

tinggi seiring dengan suiz litar dan selular. Objektif projek ini adalah untuk

mengenalpasti perkembangan Internet pada hari ini yang mampu memenuhi

kehendaknya melalui kajian terhadap pencapaian VoIP dan QoS. Tujuan projek ini

adalah, yang pertama CODECs inalah memilih beberapa criteria kemudian

mengoplikasikan ia dalam SIP server dan akhirian mengeluarkan keputusan dari

simulation untuk membuat perbandingan dan analisis QoS. Projek ini menunjukkan

protokol-protokol VoIP untuk dua pengguna yang berhubung melalui pelayan SIP

dengan tiga algorithma CODEC. Setelah mengenalpasti masalah utama dalam

bidang ini, suatu set parameter telah diambilkira bergantung kepada kesannya

terhadap persembahan suara seperti jitter, kehilangan paket, kelewatan paket dan

throughput. Projek ini akan menggunakan tiga CODEC yang ada (menukarkan suara

dari analog ke digital dan memampatkan paket tersebut) menggunakan CODEC

dengan VoIP yang paling sering digunakan seperti G.711, G.723 dan G.729.

Walaubagaimanapun, simulasi ini akan menggunakan platform NS2 dengan nilai

saiz paket dan bilangan panggilan yang berbeza. Akhir sekali, objektif utama

daripada projek ini adalah untuk mendapatkan suara yang berkualiti tinggi dengan

memilih jenis CODEC yang sesuai. Kesimpulannya, G.711 merujuk kepada teknik

apabila kualiti diperlukan kerana the high throughput dari packets, sementara G.723

membuat yang the terbaik dengan the high bandwidth bermakna ia mampu

menangani ramai pengguna. Akhirnya, G729 levvel yang tertinggi compression

ilalah teknik yang terbaik untuk ramai pengguna dan data berat hanya apabila kualiti

tidak masuk dalam akaun.

VII

TABLE OF CONTENTS

CHAPTER TITLE PAGE

DECLARATION II

DEDICATION III

ACKNOWLEDGEMENT IV

ABSTRACT V

ABSTRAK VI

TABLE OF CONTENTS VII

LIST OF TABLES XI

LIST OF FIGURES XII

LIST OF APPENDICES XV

1 PROJECT OVERVIEW

1.1. Introduction 1

1.2. Problem Background 2

1.3. Problem Statement 4

1.4. Project Objectives 5

1.5. Project Scopes 5

1.6. Project Justification 6

1.7. Report Organization 7

2 LITERATURE REVIEW

2.1. Introduction 8

2.2. VoIP (Voice over IP) 9

2.3. Network Environment for VoIP 10

VIII

CHAPTER TITLE PAGE

2.3.1 SIP (Session Initiation Protocol) 11

2.3.2 Network Simulator (NS2) 13

2.3.2.1 OTcl and C++ 14

2.4. Main Parameters in VoIP 15

2.4.1 Quality Of Service 15

2.4.2 One -way delay 17

2.4.3 Jitter 18

2.4.4 Lost Data (Packet loss) 18

2.4.5 Throughput 19

2.5. Digital Audio Compression 20

2.5.1 Bit Rate 21

2.6. CODEC 21

2.6.1 G.711 CODEC 23

2.6.1.1 G.711 Frame (Sample Rate) 24

2.6.2 G.723.1 CODEC 25

2.6.2.1 G.723.1 Frame (Sample Rate) 26

2.6.3 G.729 CODEC 26

2.6.3.1 G.729 Frame (Sample Rate) 28

2.6.4 G.728 CODEC 28

2.6.5 G.722 CODEC 29

2.6.6 GSM CODEC 30

2.7. Mean Opinion Score 30

2.8. E Model 31

2.8.1 Mapping between E Model and MOS 32

2.9. Comparison and Contrast in Codecs 32

2.9.1 Codecs with Packet loss 33

2.9.2 Codec with Throughput 34

2.9.3 Codec with Jitter 36

2.9.4 Codecs with Wi-Fi Mesh Network 38

2.9.5 Comparison Between G.711 and G.729 39

2.10. Summary 42

IX

CHAPTER TITLE PAGE

3 RESEARCH METHODOLOGY

3.1. Introduction 43

3.2. Project Structure 44

3.3. Research Methodology 45

3.3.1 Literature Review and Initial

Requirements

47

3.3.2 Design and Architecture 47

3.3.3 Select Three Existing CODECS 48

3.3.4 Simulation 48

3.3.5 Comparison 48

3.4. Software and Hardware Requirement 50

3.5. Summary 50

4 DESIGN AND IMPLEMENTATION

4.1. Introduction 51

4.2 Architecture Design 51

4.3 Implementation 53

4.3.1 Platform Preparation 54

4.3.2 Topology 56

4.3.3 Simulation Scenario 58

4.3.3.1 UDP Packet Format 58

4.3.3.2 Set the Application Agent 58

4.3.3.3 Main Scenario 59

4.4. Trace File and AWK Result 62

5 RESULT AND EVALUATION

5.1 Introduction 66

5.2 QoS Parameters Analysis 66

5.2.1 Packet Loss 67

5.2.2 Throughput 70

X

CHAPTER TITLE PAGE

5.2.3 Jitter 73

5.2.4 End to End Delay 75

5.3 Discussion 78

5.4 Conclusion 79

6 CONCLUSION

6.1 Conclusion 80

6.2 Future Work 81

REFERENCES 82

Appendices A – B 84 - 97

XI

LIST OF TABLES

TABLE NO. TITLE PAGE

1.1 Weakness For Each Codec 3

1.2 The Mean Opinion Score Scale (ITU) 4

2.1 Audio Codecs (What is a VoIP Codec, 2005) 22

2.2 The Mean Opinion Score Scale (ITU) 31

2.3 Mapping Between R Values And Estimated MOS (ITU) 32

2.4 Bit Rate Codec With Vary Packet Size (Toral and Torres,

2005)

40

XII

LIST OF FIGURES

FIGURE NO. TITLE PAGE

2.1 Interworking messages Between Two SIP Servers and

Their Client.

12

2.2 C++ and OTcl: The Duality (Network Simulator 2). 14

2.3 Digital Audio Processing (Kervy, 2006). 20

2.4 Different Bit Rate (Kervy, 2006). 21

2.5 Sample Rate for G.711. 24

2.6 Sample Rate For G.723. 26

2.7 Sample Rate For G.729. 28

2.8 Percentage Packet Losses vs. Number of Simultaneous

Nodes Using G.711 Codec as a Function of Distance to

AP (Alias and Ong, 2006).

33


Nodes Using G.723.1 Codec as a Function of Distance

to AP (Alias and Ong, 2006).

34




34

2.11 Throughput (Mbps) vs. Number of Simultaneous



35


Nodes Using G.723.1 Codec as a Function of Distance

to AP (Alias and Ong, 2006).

35

XIII

FIGURE NO.

TITLE

PAGE




36

2.14 Jitter (second) vs. Number of Simultaneous Nodes

Using G.711 Codec as a Function of Distance to AP

(Alias and Ong, 2006).

37


Using G.723.1 Codec as a Function of Distance to AP


37


Using G.729 Codec as a Function of Distance to AP


38

2.17 Maximum Jitter During One Week (Toral and Torres,

2005).

40

2.18 Maximum End-To-End Delay During One Week

(Toral and Torres, 2005).

41

2.19 Maximum Packet Loss During One Week (Toral and

Torres, 2005).

41

3.1 Project Structure Steps. 45

3.2 Research Methodology. 46

3.3 Project Operational Framework. 49

4.1 SIP’s VoIP Architecture. 53

4.2 The Flow of Simulation Steps. 54

4.3 Tcl and C++ Files. 55

4.4 Tcl Code topology. 56

4.5 NS2 NAM Topology. 57

4.6 Tcl Code Initial. 59

4.7 Tcl Code Packet Option.. 60

4.8 Tcl Code SipUdp. 61

XIV

FIGURE NO.

TITLE

PAGE

4.9 Tcl Code Scheduler. 61

4.10 Snapshot of Trace File. 63

4.11 AWK File Code for Packet Loss. 64

4.12 The Out Put from the AWK File. 65

5.1 Packet Loss for G.711, G.723 and G.729 with 64,128

and 200 Byte of Packet Size.

67

5.2 Packet Loss for G.711, G.723 and G.729 with 512 and

1000 Byte of Packet Size.

69

5.3 Throughput versus Number of Calls Using Codec

G.711, G.723 and G.729 AT 64, 128 and 200 Bytes of

Packet Size.

71

5.4 Throughput versus Number of Calls Using Codec

G.711, G.723 and G.729 AT 512 and 1000 Bytes of

Packet Size.

72

5.5 Jitter versus Number of Calls Using Codec G.711,

G723 and G.729 At 64, 128 and 200 byte of Packet

Size.

74

5.6 Jitter versus Number of Calls Using Codec G.711,

G723 and G.729 At 512 and 1000 byte of Packet Size.

75

5.7 End to End delay versus Number of Calls Using Codec

G.711, G.723 and G.729 At 64, 128 and 200Bytes of

Packet Size.

76

5.8 End to End delay versus Number of Calls Using Codec

G.711, G.723 and G.729 At 512 and 1000Bytes of

Packet Size.

77

XV

LIST OF APPENDIXES

APPENDIX TITLE PAGE

A OTcl Simulation Code 84

B Overview Tables for Over All the Results

Which Are Obtained from Trace File

85

CHAPTER1

PROJECT OVERVIEW

1.1. Introduction

Voice communication recently became daily used whether by cellular, land

phone PSTN or voice over Internet protocol (VoIP), the last one has been invented

recently, so fast VoIP became very wide among the people. Nowadays, a human can

communicate easily to all over the world whereby their IP contributed many services

and protocols. Unfortunately, until now there is no clear guarantee to transmit the data

over the network (Doherty, Anderson, 2006). Therefore, sending the samples of voice

(packets) still does not reach the satisfaction of users, due to certainly the VoIP does not

be as clear as the human conversation. Recently, after the VoIP has been invented, the

next challenge for the researchers and engineers was the quality of voice service.

Starting from converting sender’s voice from analog to digital, then sending that

digital through the network, terminating by converting back the digital frame to analog

at the receiver side, many algorithms and techniques were occurred in VoIP life cycle.

2

On the other hand, we need to improve certain techniques and codec in order to obtain

high quality of voice. Many works, tools and techniques have been published and built

with fully concerned about how to choose a proper codec techniques, the used codec

should has suitable properties and features which aim to send a light and clear voice

sample.

This proposal will investigate VoIP existing speech codecs techniques, aiming to

study and compare encoding/decoding techniques with the certain parameters delay,

jitter, throughput and packet loss, during transmitting the data through the network.

1.2. Problem Background

Any computer system has many methods to play the sound and also should have

algorithm to compress the speech data, either for storage that file or send it through the

network. However, compression the audio for sending it much more difficult than just

storage, due to it is a real time operate, attempting to make the conversation as near as

the real talk. On the other hand, when the voice navigates across many devices such as

router, server, and the media itself, those things certainly will decrease the quality of

voice until it reaches the receiver.

Not only voice compression in the sender side is a problem, but also the receiver,

the protocols between the sender and the receiver should be clear, if the sender encodes

the voice by such codec, on the other side the receiver should decodes the voice with

codec has familiar protocol with the sender (Honathan, 2007). In addition, several

codecs are not adapted with WLAN but they are with LAN.

3

Problems that might happen over VoIP can be divided into three categories

according to codec used (Honathan, 2007). Table 1.1 shows simply and generally the

weakness of each codec and where the straight. The table reviews each codec how the

jitter, delay, placket loss, and throughput have been affected to them.

Table 1.1: Weakness for Each Codec CODECS Parameters

G.711 G.729 G.723

Jitter High Low High

Delay and loss packet Low High Low

Throughput High quality Normal High

Many techniques were introduced and applied throughout the whole project

lifecycle just to make a good decision for choosing a better codec, these techniques are

differ in their objectives and appliance, but it all gathers under best effort

encoding/decoding voice to reduce the main three common parameters as mentioned

above such as jitter, delay, and packet loss.

Encoding/decoding voice are the most serious problems during one way End-to-

End VoIP (Oliver, 2000). Since other algorithms are depend on the situation of the

network. On the other word, encoding the speech from analog form to digital

representation (samples) and packetizing the data are occur in a critical time, parallel

with high level of compression. All these problems are taken into account, in order to

obtain a light data ready to send.

Users’ satisfaction also consider as a big problem, if the users want to compare

the quality of VoIP with circuit switch service (Doherty, Anderson, 2006), certainly they

4

would complain from the inaudible conversation and from the delay of voice arriving

specially if the calls come from long distance. MOS (mean opinion score) is a common

measurement tool for voice quality (Alias and Ong, 2006), as described in the ITU

recommendation P.800, the relation between audio performance characteristics and

quality score make the MOS standard for network evaluation, from the table 1.2 MOS

can be range from 5 (excellent) down to 1 (bad). Whereat MOS of 4 or higher is

generally considered toll quality, and a MOS below 3.6 results in many users who are

not satisfied with call quality.

Table 1.2: The Mean Opinion Score Scale (ITU)

MOS Quality Rating

5 Excellent

4 Good

3 Fair

2 Poor

1 Bad

From all various problems above show how really important to focus on the

quality of voice service by choosing better speech codec techniques.

1.3. Problem Statement

5

Reports (Alias and Ong, 2006; Amir, Tarik and Noor, 2005 and Kee, Yin and

Moh, 2005) have shown that VoIP projects tend to attempt many compression

techniques (CODECs) to obtain high quality of service. Similarly, they applied that

codecs to other network area. Recently, researches are encountered a same area problem

which are choosing a proper codec and control the main factors. In contrast to traditional

views, the problems within VoIP are linked with each other.

1.4. Project Objectives

The objectives of this project are stated in the following points:

1. Investigate and analyze the audio encoding/decoding techniques in VoIP.

2. Simulate the selected encoding/decoding techniques of VoIP using NS2.

3. Evaluate and test the performance of VoIP codecs.

6

1.5. Project Scope

The objectives of this study are stated in the previous section. In order to achieve

the study objectives, it is important to highlight the study area and its boundaries, which

are stated in the following points:

1. Testing and simulation are going to be used on SIP server exactly

with NS-2.

2. Only address the coding/decoding techniques.

3. Re-coding techniques will not be addressed in this project.

4. Linux Fedora Core 2 as an Operating system to install NS2.

1.6. Project Justification

The primary measurement of success VoIP quality is to perform high quality of

voice measured from users’ satisfaction. Any project has its own problems, from this

point determining the project success or fail comes from how this project can manage

and control the problems.

Initially, codecs often affect the performance of VoIP whether by increase or

decrease the quality, due to each codec is familiar with certain network such as wired or

wireless, and also some codecs are able to work well with high number of calls while

others are not. One more, some codec is utilized for compression the data. On the other

hand, codec supplies a high quality of voice but it cost high bandwidth. This project tend

to determine each situation and which the recommended codec and where to use. In

addition, this project will compare the three codec to make a clear idea where the

7

weakness and the straight for each codec or which parameter affects the QoS more than

others.

There are more than fifteen voice codecs techniques involve in voice

communication area, the project tends to select the most three common codecs which are

more used with VoIP protocols, the reason of selecting those techniques are either due to

the adapted with VoIP protocols (H.323 or waveform), or they deal well with voice

samples as packet in real time. Most of other codecs are used with special network

service, local connection, mobile GSM, or compress music files (MP3 and MP4).

1.7. Report Organization

This simple work is arranged through six chapters, which is organized as

follows:

First chapter gives an introduction to the compression the voice in VoIP field, a

problem background, problem statement, objectives, scopes, and justification of the

problem to be solved. Second chapter covers a sufficient review of previous done

researches in this area, which covers VoIP problems and some proposed published

solutions which were seen beneficial to this work. Third chapter shows the methodology

which will be used to fulfill the objectives of this work, which were mentioned earlier in

this chapter.

Fourth chapter presents the architecture design in this area, and shows the

implementation steps with the full scenario. Fifth chapter shows the results and

evaluations which are come out from the simulation. Finally, chapter 6 concludes and

discuses all the finding.

8

CHAPTER 2

LITERATURE REVIEW

2.1. Introduction

This chapter covers some literature works applied to VoIP (Voice over Internet

Protocol) application and performance. It is arranged as follows:

First, VoIP applications are discussed in a bit detail with several examples of the

methodologies and techniques, from the literature, which were tested and applied by the

researchers who have published it, and were observed and criticized by the researcher of

this simple work.

Then, study and prepare the suitable environment Network which the VoIP were

applied on with many features upon that Network. In addition, the findings of this work

researcher were pointed out.

9

Next, main measurements and testing tools were used to assessment and

evaluation this taken work.

After that, compare audio codec techniques with each other, and reasons for

selecting the chosen techniques were discussed.

Finally, a summary of the chapter is written with the main highlighted points.

2.2. VoIP (Voice over IP)

Nowadays using the telephone service either over circuit switching telephone

network or over Internet became widely used. VoIP involves digitization of voice

streams and transmitting the digital voice as packets over conventional IP-based packet

networks like the Internet, Local Area Network (LAN) or wireless LAN (WLAN)

(Alias and Ong, 2006; Oliver, 2002).

Transmitting the voice through Internet was not easy, it is really complicated

since the data stream (voice, video, or text) flow for long distances, and at that period

time the data become out of our control, therefore several techniques and protocols

have been invented to led the packets through the Internet. Recently, not only

transmitting the packets were studied but also taking in account used best effort to

obtain high qualities of service.

10

2.3. Network Environment for VoIP

Building the right infrastructure to support voice over IP was important to

guarantee obtaining high performance sending and receiving packets through the

chosen network, one of the key challenges in implementing VoIP is to design and build

an IP-based network that meets QoS requirements and is comparable in performance to

conventional circuit-switched telephone networks (Extreme Network, 2000).

The high latency forwarding and best-effort delivery provided by traditional

software based routers is generally not acceptable for streaming traffic like VoIP due to

it does not provide maximum latency guarantees or minimum bandwidth guarantees

(Extreme Network, 2000).

For example, an e-mail traffic is typically handled using the store-and-forward

process, therefore it does not need to process in real time, Conversely, VoIP traffic is a

real-time process. To complete a successful VoIP session, the network must be able to

support the streaming of VoIP packets between the two end-points for the duration of

the phone conversation. VoIP traffic requires a

network to guarantee bandwidth and capacity for VoIP traffic.

To support guarantee VoIP traffic with high reliably, a network must be able to

provide three things:

• Packet – forwarding latency.

11

• Packet – forwarding jitter.

• Guarantee network bandwidth and capacity of VoIP session

Most VoIP sessions require one-way latency of not more than about 150

milliseconds, and it should not be delays exceed approximately 300 ms due to natural

human conversation becomes difficult (Extreme Network, 2000).

2.3.1 SIP (Session Initiation Protocol)

The Session Initiation Protocol (SIP) is a signaling protocol, widely used for

setting up and tearing down multimedia communication sessions such as voice and

video calls over the Internet. Other feasible application examples include video

conferencing, streaming multimedia distribution, instant messaging, presence

information and online games.

There are main features are involved in the SIP which easily allow the voice

performance become as near as the PSTN Public Switch Telephony Network performs.

The main features related with voice communication are, first call-setup and

signaling, by building Proxy Servers and User Agents which enable some telephone

operations like dialing a number, causing a phone to ring, hearing ringback tones or a

busy signal. SIP clients typically use TCP or UDP to connect to SIP servers and other

SIP endpoints. SIP is similar to HTTP and shares some of its design principles, SIP

shares many HTTP status codes, such as the familiar '404 not found'.

12

SIP User Agents (UAs) are the end-user devices, used to create and manage a

SIP session. A SIP UA has two main components, the User Agent Client (UAC) send

messages and answers with SIP responses, the User Agent Server (UAS) responds to

SIP requests sent by the peer. SIP UAs may work in point to point mode.

Proxy, Proxy Server: An intermediary entity that acts as both a server and a client

in the same time, and also can play the role of routing, by ensure that a request is sent

to another entity "closer" to the targeted user using a proper way. Proxies are also

useful for enforcing policy for example, making sure a user is allowed to make a call or

not and so on.

SIP-ISUP interworking, the messages are between end to end and their SIP

servers like create (dialing) , modify (ringing to call or busy ringing), and terminate

communication sessions (bye), based on ISUP using SIP and IP networks, the all

interworking messages are illustrate in Figure 2.1.

13

Figure 2.1: Interworking messages Between Two SIP Servers and Their Client

In this project using NS2 allow the researcher to show the SIP parameters (packet

Size, burst time, idle time, rate, min SS7 delay, max SS7 delay, end call management)

and enable it to set a testing node to evaluate the performance of call service as will be

shown in the next section.

2.3.2 Network Simulator (NS2)

NS (network simulator) is a suitable environment tool to simulate variety of IP

networks. It implements network protocols such as TCP and UPD, traffic source

behavior such as VoIP, Video, FTP, Telnet, Web, CBR and VBR, router queue

management mechanism such as Drop Tail, RED and CBQ, routing algorithms such as

14

Dijkstra, and many other network applications, furthermore it can apply not only for

wired applications but also wireless and mobility.

NS (version 2) written in C++ and OTcl (Tcl script language with Object-

oriented extensions developed at MIT).

As shown in Figure 2.2 in a simplified user's view, NS is Object-oriented Tcl

(OTcl) script interpreter that has a simulation event scheduler and network component

object libraries, and network setup module libraries. In other words, when the

researchers need to simulate their project issue they need to write their own OTcl script

language. To setup and run a simulation network, a researcher should write an OTcl

script that initiates an event scheduler and set up all the infrastructure needed, then sets

up the network topology using the network objects and the plumbing functions in the

library, and tells traffic sources when to start and stop transmitting packets through the

event scheduler, and also the ability to change the packet size, bandwidth for the link

between two objects and many other specifications can be changed depend on the

researcher objectives and environment.

2.3.2.1 OTcl and C++

NS is written not only in OTcl but also in C++. NS separates the data path

implementation from control path implementations. In order to reduce packet and event

processing time by that the Otcl will only call a procedure from C++, the event

scheduler and the basic network component objects in the data path are written and

compiled using C++. These compiled objects are made available to the OTcl interpreter

15

through an OTcl linkage that creates a matching OTcl object for each of the C++ objects

and makes the control functions and the configurable variables specified by the C++

object act as member functions and member variables of the corresponding OTcl object.

In this way, the controls of the C++ objects are given to OTcl. It is also possible to add

member functions and variables to a C++ linked OTcl object. The objects in C++ that do

not need to be controlled in a simulation or internally used by another object do not need

to be linked to OTcl. Likewise, an object can be entirely implemented in OTcl. Figure

4.3 shows an object hierarchy example in C++ and OTcl. One thing to note in the Figure

is that for C++ objects that have an OTcl linkage forming a hierarchy, there is a

matching OTcl object hierarchy very similar to that of C++.

Figure 2.2: C++ and OTcl: The Duality (Network Simulator 2).

2.4.Main Parameters in VoIP

There are several parameters involved and effected to the performance and the

quality of VoIP. This section will define more parameters affection.

2.4.1. Quality Of Service

16

The most key requirement for successful VoIP communications is a quality of

service (QoS) (Extreme Network, 2000). Voice communications require networks with

very low latency, low jitter, and minimal packet loss. Two factors drive these QoS

requirements:

• Very high user expectations.

• The technical requirements of real-time voice communications.

Telephone users have very high expectations due to they are accustomed to the

QoS provided by the PSTN. This connection-oriented, circuit-switched network

provides each user with dedicated bandwidth for the duration of each call (Extreme

Network, 2000).

However, the users need low latency and jitter, and minimal disruption due to

"noise" on the connections. Due to of Low latency allows users to obtain approximately

natural conversations. Among different networks Users differ in their delay tolerance,

for all the service they should limit one-way delay to about 150 milliseconds (ms).

When that delay’s budget includes the processing, delays introduced by the end

systems plus the latency of the network (Extreme Network, 2000).

When coders/decoders (codecs) in VoIP terminals compress voice signals they

introduce three types of delay, therefore they contribute directly in the quality of

service. Thos types of delay are:

• Processing, or algorithmic, delay – the time required for the codec to

encode a single voice frame.

• Look ahead delay – the time required for a codec to examine part of the

next frame while encoding the current frame.

• Frame delay – the time required for the sending system to transmit one

frame.

17

The following are most commonly used ITU-T standard codecs and the amount

of one-way delay that they introduce:

• For G.711 uncompressed 64 Kbps speech adds negligible delay.

• For G.729 encodes speech at 8 Kbps and adds a one-way delay of about

25 ms.

• For G.723.1 encodes speech at 6.4 Kbps or 5.3 Kbps and adds a one-way

delay of about 67.5 ms.

In general, greater levels of compression introduce more delay and require lower

network latency to maintain good voice quality When using G.723.1 compression, with

one-way delay should not exceed: 150ms – 67.5 ms = 82.5 ms (Extreme Network,

2000).

Every VoIP service to obtain high qualities should taking in account the

following three parameters:

2.4.2. One -way delay

One –way delay it is a measurement for the taken time to obtain data across the

network, Humans are used to having conversations where they both talk at the same

time (Ixia, 2005). Most users notice when the delay is more than about 150 ms; when it

exceeds 200 ms, they realize the voice become not inaudible (Ixia, 2005).

18

One-way delay that’s measured from end to end is actually made up of four

components:

1. Propagation delay: the time to travel end-to-end across the

network. The propagation delay between Singapore and Boston is

much longer than the delay between New York and Boston (Ixia,

2005).

2. Transport delay: the taken time to navigates through the network

devices along the path, Networks with many firewalls, many

routers, and slow WANS introduce more delay than a LAN on one

floor of a building.

3. Packetization delay: the taken time for such codec to digitize

analog signal and build frames – and undo it at the other end. The

G.729 codec has a higher packetization delay than the G.711

codec, due to it takes longer time to perform its compression.

4. Jitter buffer delay: the delay introduced by the receiver to hold

one or more datagrams in the queue, when any datagram has

different time to arrive the destination (Ixia, 2005).

2.4.3. Jitter

A jitter is a value which captures the amount of variability in the arrival times

of the datagrams at the receiver (Ixia, 2005). The sending side sends datagrams at a

regular periodic rate, say every 20 or 30 ms. Ideally, the receiving side would receive the

19

datagrams at the same rate, in which case there’s no jitter. However, all kinds of things

can happen in data networks (depend on such network used). However, some datagrams

arrive quickly while others arrive more slowly or do not arrive forever. If slow

datagrams arrive too late, they are discarded to make way for the datagram that follows

them (Richard, 2002; Ixia, 2005 and Alias and Ong, 2006).

One method of damping the variability of arrival rates is to put a “jitter buffer”

between the network layer and the VoIP application. A jitter buffer holds datagrams at

the receiving side. It can compensate for variability of arrival rates and also deal with

datagrams that arrive out of order. It hands the arriving datagrams to the processing

application in order, at a more consistent rate. However, since the jitter buffer needs to

hold the datagrams for some time to do this damping, it further increases the delay. And,

compounding the problems somewhat, datagrams can be lost when a jitter buffer is

overrun.

The common reason of jitter occurrence was low bandwidth. As mentioned previously

adding buffer to reduce jitter, obviously with too much buffering the latency will be

increase (Richard, 2002).

2.4.4. Lost Data (Packet loss)

Datagrams that are lost generally can not be recovered, obviously the voice

momentary gaps in the conversation. Some tiny gabs can not be realized by human ear,

while high rate of datagrams lost or periods where lots of datagrams are lost will disturb

a human listeners (Ixia, 2005).

20

On the other hand, Packet loss is also caused when the network is congested due

to insufficient bandwidth. Audio and video can handle this to a certain extent, but too

much and quality will be reduced.

In addition, Availability of the route after it has been setup is also important. If a

route was to become unavailable during a call then it would be necessary to find a new

one, before too much data was lost (Richard, 2002).

In the next sections after the codecs have been chosen we will apply them to each

previous parameter, from those parameter can help to make a good decision to choose

our codecs.

2.4.5. Throughput

The throughput (measured in bps) corresponds to the amount of data in bits that

is transmitted over the channel per unit time (Alias and Ong, 2006). the throughput

differs from codec to other, many studied have found that G.711 has a highest

throughput (Alias and Ong, 2006; Amir, Tarik and Noor, 2005 and Kee, Yin and Moh,

2005).

2.5.Digital Audio Compression

21

This section is the core work and the important issues in VoIP, compressing

audio is main factor for transmitting the voice through the network, and all researches

working carefully in this field, in order to send a light data we should prepare and

choose good techniques for compressing the audio. When a human voice is analog frame

certainly first we need to convert it to digital presentation in order to send it through the

network.

The conversion from the analog to the digital domain begins by sampling the

audio input in regular, discrete intervals of time and quantizing the sampled values into a

discrete number of evenly spaced levels (Davis, 1993). The digital audio data consists of

a sequence of binary values representing the number of quantizer levels for each audio

sample. The method of representing each sample with an independent code word is

called pulse code modulation (PCM). Figure 2.3 shows the digital audio process.

Figure 2.3: Digital Audio Processing (Kervy, 2006).

22

2.5.1. Bit Rate

It is a main factor to determine the level of such chosen compression technique.

Bit rate refers to the number of bits per second devoted to storing the final product; the

higher the bit rate, the greater the audio resolution of the final product (Kervy, 2006). On

the other hand, means less data is distributed over a given time frame. Figure 2.4 shows

more bits per second means more audio resolution.

Figure 2.4: Different Bit Rate (Kervy, 2006).

The remaining of this chapter will illustrate the main part from my work and

other researcher works. How to choose the compression techniques (CODECS) taking in

account the previous points (e.g. Bitrate, delay, jitter, and loss packet). Analyze and

study each codec in order to obtain a proper decision to choose our technique codec,

then find out the performance for each codec by applying them on several testing

methods (QoS and MOS), finally, many comparisons have been done among several

chosen codec in this chapter.

2.6.CODEC

23

Speech coding is the application of data compression of digital audio signals

containing speech, with many kinds of codecs either speech codec or voice codec

commonly used with VoIP and mobile telephony. Table 2.1 shows the codecs with their

algorithms and bitrates

Table 2.1: Audio Codecs (What is a VoIP Codec, 2005)

Codec Algorithm Bit Rate

(Kbps) Comments

ITU G.711 PCM (Pulse Code Modulation) 64 G.711 with mu-law used in North America and Japan,

while G.711 with A-law used in the rest of the world.

ITU G.722 SBADPCM (Sub-Band Adaptive Differential

Pulse Code Modulation)

48, 56 and

64

ITU G.723 Multi-rate Coder 5.3 and 6.4

ITU G.726 ADPCM (Adaptive Differential Pulse Code

Modulation)

16, 24, 32,

and 40

ITU G.727 Variable-Rate ADPCM 16-40

ITU G.728 LD-CELP (Low-Delay Code Excited Linear

Prediction) 16

ITU G.729 CS-ACELP (Conjugate Structure Algebraic-

Code Excited Linear Prediction) 8

ILBC Internet Low Bitrate Codec 13.33 and

15.20

Speex CELP (Code Excited Linear Prediction) 2.15-44.2 Part of the GNU Project and available under the Xiph.org

variant of the BSD license

GSM - Full RateRPE-LTP (Regular Pulse Excitation Long-Term

Prediction) 13

GSM - Enhanced

Full Rate

ACELP (Algebraic Code Excited Linear

Prediction) 12.2

http://en.wikipedia.org/wiki/Data_compression

http://en.wikipedia.org/wiki/Digital_audio

http://en.wikipedia.org/wiki/Speech

http://www.speex.org/

http://kbs.cs.tu-berlin.de/~jutta/toast.html

24

GSM – Half Rate CELP-VSELP (Code Excited Linear Prediction -

Vector Sum Excited Linear Prediction) 11.4

DoD FS-1016 CELP (Code Excited Linear Prediction) 4.8

In this chapter relatives with other researchers work the chosen codec are three

most common used with VoIP (G.711, G.723, and G729), the following sections will

illustrate with detail the features and the performance of each three and the rest codecs

with some comparison between the three codecs.

2.6.1 G.711 CODEC

G.711 is a most commonly supported voice companding algorithm used in

telephony (International Telecommunication Union–T Recommendation ). It has

become the de facto standard used to ensure high performance in voice over Internet

protocol (VoIP) applications ( Vocal Technologies, 2007). Compression is performed on

a per sample basis with each uniformly quantized sample producing an 8-bit pulse code

modulated (PCM) or companded value. G.711 standard that allow telephony equipment

to reduce network traffic by transmitting minimal data during periods of silence and to

improve playback quality by synthesizing speech during periods when data has been lost

or corrupted (Adaptive Digital Technologies, 2006).

There is two Adaptive Digital’s G.711 coder converts between 8-bit mu-law

(American and Japan standard) or a-law (European and rest world standard)

(International Telecommunication Union –T Recommendation).

http://rice.ecs.soton.ac.uk/jason/speech_codecs/standards/dod_celp.html

25

G.711 mu-law (optional) is a highly effective algorithm for concealing lost

packets of G.711 data. Voice signals are packetized during the periods when data is

unavailable for real-time playback (silent period). With G.711 speech remains audible

even under conditions where the packets lost are 30%.

G.711 a-law (optional) provides three algorithms, voice activity detection

(VAD), discontinuous transmission (DTX), and comfort noise generation (CNG). These

algorithms provide an efficient method for reducing packet bandwidth during portions of

a conversation when no voice activity is present (International Telecommunication

Union –T Recommendation).

- Features of G.711.

• Bitrate is 64 kbps.

• Mu-law and a-law support.

• ITU G.711 Compliant

• Optional voice activity detection (VAD) with discontinuous transmission

(DTX) and comfort noise generation (CNG) for bandwidth reduction.

• Robust packet loss concealment for improved voice quality during

periods of missing packets.

• Multi-channel capable.

• C Callable.

2.6.1.1. G.711 Frame (Sample Rate)

It is a sample based codec [ITU]. That means each frame in this codec consists of

8 samples, one frame presents 1ms. Figure 2.5 shows the rate of this codec samples.

26

Figure 2.5: Sample Rate for G.711

2.6.2 G.723.1 CODEC

G.723.1 specifies a coded representation that can be used for compressing the

speech or other audio signal component of multimedia services at a very low bit rate

(Daniel and Emma, 2002). In the design of this coder, the principal application

considered was very low bit rate. G.723.1 has two bit rates associated with it, 5.3 kbit/s

and 6.3 kbit/s. The higher bit rate has better voice quality. The lower bit rate still gives

good quality and provides system designers with additional flexibility. Both rates are a

mandatory part of the encoder and decoder, it is possible to switch between the two rates

at any 30 ms frame. This codec use SID (Silence Insertion Description) frames.

(International Telecommunication Union –T Recommendation; Alias and Ong, 2006 and

Oliver, 2002).

Features of G.723.1

• Bit rate 5.3 or 6.3 kbps.

• Sampling rate: 8 kHz

• Delay: 37 msecs.

• eXpress DSP™ Compliant.

• Functions are C-callable.

• Capable of in-band synchronization.

27

• Can be integrated with echo cancellers, and tone detection/regeneration.

• The encoder and decoder meet all ITU G.723.1 compliance and

interoperability requirements.

2.6.2.1. G.723.1 Frame (Sample Rate)

It is a frame based codec (International Telecommunication Union –T

Recommendation). That means each frame in this codec consists of 240 samples, one

frame presents 30ms. Figure 2.6 shows the rate of this codec samples.

Figure 2.6: Sample Rate For G.723

28

2.6.3 G.729 CODEC

The G.729 speech coder is an 8 kbps using algorithm Conjugate-Structure

Algebraic-Code-Excited Linear Prediction (CS-ACELP) (International

Telecommunication Union –T Recommendation). Speech compression algorithm

approved by ITU-T. G.729 offers high quality, great speech performance at the price of

complexity. It requires 10 ms input frames and 80 bits for generating frames in length.

With the G.729 coder processing signals in 10 ms frames and a 5 ms look-ahead, the

total algorithmic delay is 15 ms (Alias and Ong, 2006 and Oliver, 2002).

G.729 is an umbrella of vocoder standards, it has wide extension of annexes:

G.729 Annex A specifies a reduced complexity G.729A coder with several

simplifications, involving code book search routines and the decoder postfilter among

others. These modifications may result in slightly lower voice quality.

G.729 Annex B defines a G.729B coder that uses Discontinuous Transmission

(DTX), Voice Activity Detection (VAD), and Comfort Noise Generation (CNG) to

reduce bandwidth usage by preventing the transmission of any non-voice frames during

periods of silence.

G.729 Annex D uses 6.4 kbps CS-ACELP compression and G.729 Annex E uses

11.8 kbps CS-ACELP compression.

Features of G.729.

http://www.vocal.com/data_sheets/g729d1.html

http://www.vocal.com/data_sheets/g729d2.html

29

• Delay: 5 milliseconds algorithmic delay, 10 milliseconds framing delay.

• Functions are C-callable.

• Multi-channel capable.

• The encoder and decoder meet all ITU G.729 compliance and


• Can be integrated with echo cancellers.

• Capable of in-band synchronization.

2.6.3.1. G.729 Frame (Sample Rate)

It is a frame based codec (International Telecommunication Union –T

Recommendation). That means each frame in this codec consists of 80 samples, one

frame presents 10ms. Figure 2.7 shows the rate of this codec samples.

Figure 2.7: Sample Rate For G.729

30

2.6.4 G.728 CODEC

G.728 has rapidly gained acceptance for many applications including satellite,

cellular, and video conferencing systems (International Telecommunication Union –T

Recommendation). In fact, G.728 is specified as part of the H.320 international video

conferencing standard. The reason for this rapid acceptance is that G.728 delivers the

same toll quality voice as 32 kbps ADPCM in only half the bandwidth. The Adaptive

Digital G.728 software is DAIS compliant.

• Coding Rate: 16 kbps, 12.8 kbps, 9.6 kbps selectable at run time on the fly.

• Sampling Rate: 8 kHz.

• Delay: 2.5 msec (algorithmic) .

Features

1. Functions are C-callable .

2. Can be integrated with echo cancellers, VOX and tone

detection/regeneration.

3. C The encoder and decoder meet all ITU G.728 compliance and


4. Optional in-band synchronization available.

5. Adaptive Digital's G.728 C54x is xdais compliant.

31

2.6.5 G.722 CODEC

The Adaptive Digital Technologies G.722 Audio Coder is a real-time

implementation of the ITU G.722 audio coder (International Telecommunication Union

–T Recommendation ). It is used with many applications that require audio frequency

bandwidth coding such as video conferencing, multimedia, and speaker/microphone

digital telephony. The G.722 audio coder encodes 16 kHz sampled audio signals for

transmission over 48, 56, and 64 kbps channels, and provides 7 kHz of audio bandwidth.

2.6.6 GSM CODEC

GSM-AMR is an adaptive multi-rate speech coder that has been standardized for

use in Third Generation (3G) mobile telephony (International Telecommunication Union

–T Recommendation). The coder supports eight bit rates: 12.2, 10.2, 7.95, 7.40, 6.7, 5.9,

5.15, and 4.75 kbps. The coder uses algebraic code excited linear prediction (ACELP)

as the compression method. AMR also includes Voice Activity Detection (VAD) and

Discontinuous Transmission (DTX) as an added way to save bandwidth by sending

fewer bits per second when the user is not speaking. GSM-AMR was developed to

maintain high speech quality under a wide range of transmission conditions.

• Coding Rate: 12.2, 10.2, 7.95, 7.40, 6.7, 5.9, 5.15, and 4.75 kbps.

32

• Sampling Rate: 8 kHz.

• Delay: 20 milliseconds .

2.7. Mean Opinion Score

The most common tool measurement of voice quality is the MOS, as described

in the ITU Recommendation P.800. The relation between audio performance

characteristics and a quality score makes the MOS standard valuable for network

assessments (Alias and Ong, 2006), benchmarking, tuning, and monitoring. From Table

2.2 MOS can be range from 5 (Excellent) down to 1 (Bad).

Table 2.2: The Mean Opinion Score Scale (ITU)

MOS Quality Rating

5 Excellent

4 Good

3 Fair

2 Poor

1 Bad

33

A MOS of 4 or higher is generally considered toll quality (as per voice call in

PSTN). A MOS below 3.6 results in many users who are not satisfied with the call

quality (Alias and Ong, 2006).

2.8. E Model

E-Model (Christin, 2004 and International Telecommunication Union-T

Recommendation P.59 ) provides a powerful method of testing whether a WLAN data

network is capable and ready to carry VoIP calls through network as well as performing

voice-readiness testing (Alias and Ong, 2006).

An E-model calculates all of the following factors: delay, percentage of packets

lost, delay introduced by the jitter buffer, and the performance of the codec. Once the R

value is calculated from these factors, an estimate of the MOS can be directly calculated

from it. Furthermore, the maximum number of simultaneous of VoIP calls that can be

handled by the WLAN will be determined.

2.8.1. Mapping between E Model and MOS

R factor values range from 100 (desirable) down to 0 (unacceptable)

International Telecommunication Union-T Recommendation P.59; G.114 and G.107).

Once the value of R is calculated from these factors, an estimate of the MOS can be

directly calculated using the following formula:

MOS = 1 < 1 + (0.035*R) + (R(R – 60)*(100 – R)*7.0e-06) < 4.5 (1)

34

From Table 2.3, R factor values from the E-model are shown on the left, with

their corresponding MOS values on the right. The likely satisfaction level of human

listeners is shown in the middle.

Table 2.3: Mapping Between R Values And Estimated MOS (ITU) R User Satisfaction MOS

90-100 Very Satisfied 4.3-4.5 (Desirable)

80-90 Satisfied 4.0-4.3 (Desirable)

70-80 Some users dissatisfied 3.6-4.0 (Acceptable)

60-70 Many users dissatisfied 3.1-3.6 (Acceptable)

50-60 Nearly all users dissatisfied 2.6-3.1 (Not recommended

0-50 Not recommended 1-2.6 (Not recommended)

2.9. Comparison and Contrast in Codecs

This section will illustrate a vary researches which have been compared chosen

codecs depend on parameters (packet loss, throughput, and jitter).

2.9.1. Codecs with Packet loss

Packet loss is an important parameter affecting the performance of VoIP, other

researches have been studied and analyzed how the G.711, G.723.1 and G.729 were

affected with packet loss, G.711 clearly suffers from the packet loss compare with

G.723.1 and G.729. Generally, packet loss is related with the packet length, which is

proportional to transmission time associated with each packet. Furthermore, the time

intervals between packets are shorter in G.711, which decreases the performance in

terms of dropped packets (Alias and Ong, 2006). This research have been applied the

codecs within VoIP over WLAN, it has measured the packet loss according to the

35

number of nodes and the distance to/from the AP (access point). Figure 2.8 shows the

percentage of packet loss with G.711.

Figure 2.8: Percentage Packet Losses vs. Number of Simultaneous Nodes

Using G.711 Codec as a Function of Distance to AP (Alias and Ong, 2006).


Using G.723.1 Codec as a Function of Distance to AP (Alias and Ong, 2006).

36


Using G.729 Codec as a Function of Distance to AP (Alias and Ong, 2006).

2.9.2. Codec with Throughput

The throughput (measured in bit per second) corresponds to the amount of data

in bits that is transmitted over the channel per unit time. Other researches have studied

and analyzed each codec how much throughput was obtained then comparison with

others codecs. In this study the number of nodes and their distance from the access point

will affect to the throughput. G.711 gives the highest throughput for the same number of

simultaneous nodes and distances (Alias and Ong, 2006). Figures 2.11, 2.12 and 2.13

show the throughput for each codec vs. number of simultaneous nodes as a function of

distance from/to AP.

37

Figure 2.11: Throughput (Mbps) vs. Number of Simultaneous Nodes Using

G.711 Codec as a Function of Distance to AP (Alias and Ong, 2006)


G.723.1 Codec as a Function of Distance to AP (Alias and Ong, 2006)

38



2.9.3. Codec with Jitter

The same research has been studied and analyzed codec with jitter either, this

parameter were measured using the formula below:

Jitter ＝ current packet received time - last packet received timedifferential of sequence number between two packet

Jitter is defined as a variation rate in the delay of received packets (Alias and

Ong, 2006). We can notice that irrespective of the packet size and amount of data sent,

the jitter value does not vary much. The researcher has found out jitter delay for G.723.1

is bigger than G.729 and G.711 as many small size packets are generated with variant

inter-arrival time. As the maximum packet size is increased to 120 bytes for G.711, the

39

jitter is less significant as a smaller number of packets with less delay variations are

generated. Figures 2.14, 2.15 and 2.16 will illustrate that.

Figure 2.14: Jitter (second) vs. Number of Simultaneous Nodes Using



G.723.1 Codec as a Function of Distance to AP (Alias and Ong, 2006)

40



2.9.4. Codecs with Wi-Fi Mesh Network

The three codecs (G.711, G.723 and G.729.2) of an IEEE 802.1 lb based Wi-Fi

mesh network with chain topology has been studied and found out the following, that

G.729.2 was performed better in terms of jitter and packet loss as compared to G.71 I

and G.723 (Kee, Yin and Moh, 2005). In addition, carried out using G.729.2, packet loss

which is related to the available network capacity (Cisco Document server), is found to

be the main limiting factor that prevents a wireless mesh network from supporting

higher number of users. This result is different from the saying that jitter is the limiting

factor in supporting voice calls over IP.

41

2.9.5. Comparison Between G.711 and G.729

Other study has been analyzed the two codecs (G.711 a-law/u-law and G.729

VAD/no VAD) according to vary packet size the maximum values for the jitter Obtained

the highest values for the jitter arise when the G.729 codec VAD/No VAD was used

with packet sizes of 40ms (110 bytes) and 60 (138 bytes). From this, we can conclude

that the jitter tends to increment when:

1. Either the level of voice compression increments (lower bit rat) (Toral and

Torres, 2005).

2. Or the packet size increments (Toral and Torres, 2005).

But when G.711 has been used with the same size of packet size of 20ms (214

bytes), 40ms (374 bytes) and 60ms (534 bytes), we will find the end-to-end delay has

maximum magnitude values arise when the calls employed the G.711 a law/u law codec

with that packet sizes, this is due to (Toral and Torres, 2005):

1. the codec generates packets with large sizes and,

2. It does not make any voice compression.

As conclusion, since a codec perform a high performance of voice compression

will obtain large values of jitter, however this coded will not overload the network, but if

the codec does not perform any voice compression, it will overload the network,

generate a large values of packet losses and end-to-end delays, but the voice qualities

will have high level performance. In addition, there is a direct relation between the end-

to-end delay and the packet loss. If large values of end-to-end delay are present, then

42

there are high levels of packet loss. Therefore is important to manage our choice

between selecting a codec and the packet size (Toral and Torres, 2005).

Table 2.4: Bit Rate Codec With Vary Packet Size (Toral and Torres, 2005).

Figures 2.17, 2.18 and 2.19 illustrate and summarized what the research has

found above (Toral and Torres, 2005).

Figure 2.17: Maximum Jitter During One Week (Toral and Torres, 2005).

43

Figure 2.18: Maximum End-To-End Delay During One Week (Toral and

Torres, 2005).

Figure 2.19: Maximum Packet Loss During One Week (Toral and Torres,

2005).

44

2.10. Summary

In this chapter, literature review was conducted to explore the area of

compression the voice in VoIP and its different issues. Reasons of traffic VoIP were

explored, and then the suitable environment network were explained and equipped with

examples.

The last part was a summary of techniques, tools, and mechanisms that were

explained with findings and results pointed out, this part helped the researcher to select

the techniques that will be used in this project.

In this work, prototyping and generalization are the techniques that interest the

researcher, and they will be used in his methodology for choosing a better voice codec

methodology, that aims to improve the quality of encoding/decoding and lower the

weakness during navigation through various networks, and finally, control and prepare

smooth data ready to transmit through the network with best effort avoiding any long

delay or lost in the samples (packets).

45

CHAPTER 3

RESEARCH METHODOLOGY

3.1. Introduction

All the steps in this project are illustrated as a sequence of methodical work in

this Chapter, this step are guiding the work through a research lifecycle, to meet and

achieve all the objectives which have been conducted for.

The purpose from the methodology in this project is not only makes the research

understood and clear for the researcher, but also will simplify the project flow, guides

the best practices, and gives high ability to explain alternative options when the

problems appear in any phase in all lifecycle of the project. In addition, methodology

assists the researcher to know where the efforts are.

This chapter is the methodology and framework which are used in this project.

The first section shows the project structure. Then, it is followed by project operational

46

framework. Next, the methodology of the techniques will be highlight. Finally,

mentioned about the equipments and software tools which will used gather through this

project. Conclusion of this project will be in the end.

3.2. Project Structure

Determining and defining the problems are first things usually mention in any

project, with the domain and scope for the problems thus it becomes the basic point

where the researcher starts the work.

Then collecting a related data from others work helping much to enhance work,

taken into account choosing the data should be done carefully in order to obtain correct

information, due to this data might the researcher will rely on it. Moreover, this data will

be analyzed and criticized as well.

Next step is an implementation to the information which has been collected, then

study and analyze on such data. Finally, all the finding in this work will be obtained.

Figure 3.1 presents common project structure in research.

47

Problem Definition

Data collection and analysis

Figure 3.1: Project Structure Steps

3.3. Research Methodology

This section will carry out the main steps for this project to achieve the

objectives. The main purpose from this section is to make a good schedule helping the

researcher to develop any part in this project. Figure 3.2 shows the research

methodology (Gary, 1999) which is used in this project.

Simulate the codecs with different cases by (NS2)

Investigate and select 3 existing codec

Findings and Result

48

Figure 3.2: Research Methodology

49

3.3.1 Literature Review and Initial Requirements

With an intensive study from the researcher with frequent advices from the

supervisor, VoIP area is an interesting topic among Networking field, which led the

researcher to choose this area. Moreover, after an intensive reading and investigate in

VoIP problems, the researcher come out with wide background to choose

encoding/decoding as a main topic for this project.

After the topic has been chosen, the next step is to collect a benefit data and

resources. Detailed study and narrow down in each problem with study several proposes

to solve this problem.

Researcher has reviewed literature from books, some Internet articles and soft

copies of journals, in the beginning, the definitions and the explanations of the most

common features in this field are reviewed. In addition, the mechanisms for each codec

are studied either. Furthermore, the differences between the codecs are compared in the

late of this step.

3.3.2 Design and Architecture

In this phase the main components are design and prepare all the software and

hardware requirements in order to make end to end voice call using SIP server. In

addition, NS2 platform is place in this phase.

50

3.3.3 Select Three Existing CODECS

Select three existing encoding/decoding of VoIP in term of the performance with

certain parameters for each codec, taken into account the advantages and the limitation

for each codec.

3.3.4 Simulation

The three codecs which are selected will simulate to come out with the result

from each situation the codec involves, using software Network Simulator 2 (NS2)

under Linux operating system.

3.3.5 Comparison

The results from the simulation will measured and evaluated by comparing the

parameters of each codec applied with different cases. Finally, the project will come out

with the evaluated finding.

Figure 3.3 shows Project Operational Framework.

51

Simulation

Compare the parameter results from the simulation for codec with each other

optimization

No

Yes

Increase or decrease in the key

parameters

Reviewing and studying the features’ research base on voice codec

Apply voice codec optional keys base on what have been done before to simulate with different cases

Codecs selection

Finding and Results

Figure 3.3: Project Operational Framework

52

3.4. Software and Hardware Requirement

This section lists the software which will be used through this project. This helps

to make the project clear and easy.

Requirements which are used in this project.

1. Linux Fedora Core 2 with NS2.

2. Microsoft Windows XP Professional.

3. Microsoft Office 2003 Professional.

4. Microsoft Paint.

5. Adobe Acrobat Professional 8.0.

6. Normal PC: Pentium 3.

3.5. Summary

This chapter has explained the methodology that will be followed to achieve

project objective. In this chapter also the operational framework is discussed to show the

highlight points and where the concentrated parts, to make the project process clear and

guided. Hopefully, this methodology will serve the objectives of this project as well.

53

CHAPTER 4

DESIGN AND IMPLEMENTATION

4.1 Introduction

In this chapter, the platform of the simulation is designed using NS2 (Network

Simulator 2). Highlight the features of SIP server (Session Initiation Protocol) as a soft

telephony protocol. In addition, install SIP server on NS2. Then show the scenario and

the topology of the project in NS2. Furthermore, there are a certain parameters which are

involved in the simulation.

4.2 Architecture Design

In order to make a successful platform environment for sending data of voice

simulation, SIP server is a proper choice to publish call(s) via network with two nodes

54

(sender and receiver) using IP address. SIP server code is applied and installed in NS2,

features and properties of SIP server are customized to fulfillment the objectives.

However, the main components to design a voice traffic platform are sender which sends

a talk or silent analog frame and the receiver in the other side to receive a call. Whereby,

many devices and algorithms are involved between the two sides, as below.

1. Encoder and Packetizer (sender side) to convert and compress the

analog frame to digital frame followed by packetize the samples as

packets and inject through the network.

2. Depacketizer and Decoder (receiver side) to decompress the received

packets and convert back from digital to analog frame.

3. Two SIP servers are attached with each sending or receiving nodes.

From the simulation part, NS2 is the main environment where the SIP code is

applied by contributes the SIP code to Tcl script which is the interface for the researcher,

from Tcl script the topology graph and the results are obtained to make comparison and

analysis study. Figure 4.1 illustrates the main components which are involved in the

project.

55

Figure 4.1: SIP’s VoIP Architecture.

4.3 Implementation

Figure 4.2 shows the flow of the simulation steps starting from Tcl script. The

simulation is run for 15 times (3 codecs applied to 5 packet sizes), each time the

simulation creates Trace File, from this trace file the visualization results (Nam Figure

4.5) and numeric results (AWK) are obtained. Whereby, the Nam file is monitored to

show the main topology for the network. On the other hand, AWK file displays the

percentages and the values of the main parameters. Finally, the results are obtained form

the simulation for analysis.

56

Figure 4.2: The Flow of Simulation Steps.

4.3.1 Platform Preparation

NS2 program is installed in a Linux Fedora or cygwin under Windows.

However, Linux Fedora core 2 is used as a platform for the simulation due to the ns-

allinone2-26 limitation. While SIP softphone code also only works with ns-allinone2.26

due to the SIP limitation, this version of NS2 has high ability to run SIP code after

installing the patch file in NS2-26. One more, there are several files need to place inside

the platform, the files are for some functions such as the packet header, trace file and

other C++ files shown in Figure 4.3.

57

-sip_udp.cc

-sip_udp.h

-sip_sctp.cc

-sip_sctp.h

-packet.h

-trace.cc

-udp_sip.cc

-udp_sip.h

-sctp.h (modified)

-sctp.cc (modified)

-ns-defaults.cl

Figure 4.3: Tcl and C++ Files

There are cooperating C++’s files which the Tcl needs to call them as procedures

to operate some functions related with SIP properties such as:

with codec_selector _ ON ---------------------(SIP uses its default codec)

with codec_selector_ OFF --------------------(it is a customized option)

with end_call_managment_ ON -------------(enable user to customize the call time)

After the software code components are set, the infrastructure need to set as a

topology in the simulation, which contain from:

1. Two SIP proxy servers.

2. Two sending nodes.

3. Two receiving nodes.

4. Two nodes for testing voice packets.

5. Four nodes for navigation throw the network.

58

Figure 4.4 shows the Tcl code lines for creating the topology of the Nam

visualization monitor.

#topology # nodes set LO1 [$ns node] set LO2 [$ns node] set TO1 [$ns node] set TO2 [$ns node] #node of SIP proxy server set PR1 [$ns node] set PR2 [$ns node] set n_voice_($to) [$ns node] set n_null_($to) [$ns node] set n_voice_($from) [$ns node] set n_null_($from) [$ns node] #node of voicetest set n_test_1 [$ns node] set n_test_2 [$ns node] set WEB2 [$ns node]

Figure 4.4: Tcl Code topology

4.3.2 Topology

Considering that, the network topology consists of two SIP Proxy servers

(PR1 and PR2), along with node for sending voice n_voice and node for receiving call is

n_null for each server, which means n_voice1, n_voice2, n_null1 and n_null2. In

addition, one node for testing, cooperating with each server is attached with sending or

receiving node (n_test1 and n_test2). Furthermore, four nodes are created between the

two side (sender and receiver) those nodes are form the navigation purpose they are L1,

59

L2, T1 and T2 as shown in the NAM graph in Figure 4.5. Associated with, physical

connection link between all the nodes and servers is also customized as duplex-link with

speed 155Mb with 5ms of propagation delay between the 4 nodes of navigation L1, L2,

T1 and T2 (Michele Luca,1996). 0ms propagation delay is set between the two testing

voice, it set 0ms to avoid any delay by that it dose not effect the main delay of the

simulation. Finally, 20ms is set between the servers and the nodes (sender and receiver)

(Michele Luca, 1996).

L2=0 PR1=4 n_voice1=7 L1=1 PR2=5 n_voice2=9 T2=2 n_null1=6 n_test1=10 T1=3 n_null2=8 n-test2=11

Figure 4.5: NS2 NAM Topology

60

4.3.3 Simulation Scenario

Exponential traffic voice (created packet while talk period for 1.00ms and no

packet is created during 1.3ms of silent period) is a scenario in the implementation using

SIP to fulfill sending voice packet from end to end nodes.

4.3.3.1 UDP Packet Format

UDP transport protocol is used to transmit the packets. A typical packet size

is 200 bytes (12 bytes RTP header + 8 bytes UDP header + 20 bytes IP header + 160

voice data) (ITU). Hereby, increasing the value of packet size is the main function

considers in this simulation, in order to study the performance and QoS of VoIP with the

certain parameters and how the packet size is effected each simulation. However, the

following vary values of packet size are applied in the simulation (64, 128, 200, 512 and

1000) (Michele Luca, 1996).

4.3.3.2 Set the Application Agent

Application sits on top of transport agent in NS2, the type of traffic that

attached to UDP transport agent in simulation is exponential traffic. Exponential traffic

object generates ON/OFF traffic period. During “ON’ period, packets are generated at

constant burst rate. While on “OFF” period, no packet is generated. Burst time and idle

times are taken from exponential distributions (Michele Luca, 1996).

The exponential traffic was chosen due to in the conventional model, each

voice source alternates between talk “ON” and silence “OFF” periods, which are

61

independent and exponentially distributed. During an active period SIP data is generated

and no data is transmitted during the silence period. As (ITU) default average burst time

is equals to 1.00 second while average idle time is equals to 1.3 second.

4.3.3.3 Main Scenario

In a fair manner the NS2’s Tcl code is customized, that enable such

parameter to be changed such as number of calls, simulation time, call time, SIP packet

size, voice packet size, voice rate and interval time between two generated packet, and

much more parameters are involved in NS2. In initial stage of the simulation, three

important parameters need to set due to they are effect the performance of the call as

show in Figure 4.6.

set N 10 ;calls -------------- (set the number of calls) set simtime 10 -------------- (set the simulation time) set call_time 10-------------- (set the call time)

Figure 4.6: Tcl Code Initial

Secondly, the other important stage in this simulation is what the properties

of the call packet are, since they are the main function presented in this simulation,

whereas from the options the three speech codecs are design.

62

set voice_packet_size 160 -------------- (the typical packet size) set voice_burst_time 1.0 -------------- (the ON period, talking time) set voice_idle_time 1.3 -------------- (the OFF period, silent time) set voice_rate 64000 -------------- (bit rate bit/sec) set tidle 1 -------------- (talking time) set ttotal 2.3 -------------- (all time)

Figure 4.7: Tcl Code Packet Option

There are 15 simulations in the implementation, since 3 codecs are closed

and each codec is simulated with 5 values of packet size. All those simulations are

managed at the previous code sentences by set voice_rate 64000, 6500 and 8000 each

simulation time run one of the selected codecs G.711, G.723 and G.729 respectively.

Participated with, the packet size is set to voice_packet_size 24, 88, 160, 472 and 960.

Hereby, IP, RTP and UDP header which are 40 bytes are not included in the packet size.

Finally, the SIP servers are managing the main scenario for making and

controlling a call by connecting the two nodes via external connection after the called

node answer the call, no more SIP use. The applications of the SIP traffic mode are

involved in the project code either, they are set default as code lines in Figure 4.8.

63

set sip [new Application/Traffic/SipUdp] $sip_2 set packetSize_ ${sip_packet_size} $sip_2 set burst_time_ 0 $sip_2 set idle_time_ interarrival $sip_2 set rate_ 2.5Mb $sip_2 set print_ 0 $sip_2 set minSS7delay_ 0.025 $sip_2 set maxSS7delay_ 0.05 $sip_2 set end_call_management_ 1 $sip_2 set call_min_ 90 $sip_2 set call_max_ 120 $sip_2 set from_ $to $sip_2 set to_ $from $sip_2 set codecselector_ 0 $sip_2 set siptimer_ 0 $sip_2 attach-agent $udp_2

Figure 4.8: Tcl Code SipUdp

In order to terminate the simulation, There are several steps are set in the end

of the Tcl code start the call(s), end the call(s), start voice tester and stop voice tester as

illustrate in Figure 4.9.

#scheduler set fintime [expr $simtime + $call_time] $ns at 0.0 "$sip_1 start" --------(SIP1 start at 0.0 second) $ns at 0.0 "$sip_2 start" --------(SIP2 start at 0.0 second) puts "start_sip" $ns at 0.0 "$voice_test start" -----(voice tester start account at 0.0) $ns at $fintime "$voice_test stop" $ns at $simtime "$sip_1 stop" ---(SIP1 stop at simulation time) $ns at $simtime "$sip_2 stop" ---(SIP1 stop at simulation time) $ns at $fintime "finish" $ns run

Figure 4.9: Tcl Code Scheduler

64

The telephony softphone call scenario is operated as a following protocol as

1. n_voice1 want to make a call to n_null2, that means the SIP1 server

2. ich has the target address (n_null2).

ck

4. ne (one way sending voice).

n_voice1 and

In this topology the n_test1 attached with the caller and called related with

.4 Trace File and AWK Result

At the end of each simulation, all the data are recorded with all details in a trace

file suc

explained with details in Chapter 2:

check up in its data base whether this n_null2 available or not by

searching for its related server.

SIP1 sends invitation to SIP2 wh

3. SIP2 tells null2 that there is a call from n_voice1, then send ba

acknowledgment to SIP1.

n_voice1 will hear a ring tu

5. When n_null2 answer, SIP1 and SIP2 will connect

n_null2 together directly by an external link, by that no need for the two

SIP server any more until n_voice1 or n_null2 terminate by sending

“Bye” to its SIP.

each server in order to calculate and record the entire data with all details accrued, this

data are studied and analyzed in order to evaluate the results of this simulation. This

simulation applied in the first with G.711 codec then applied with the other two codes

G.723 and G.729.

4

h as how many packet sent, how many packet received and what the time for

sending. This trace file is created in the directory of NS2 in type of out.tr as show in

Figure 4.10. Basically, the first raw flag by (+) present the information of sending

packet, while the second raw with (-) present the information of receiving packets, and

the third raw staring with ( r ) gives all the information about the given time from send

65

to receive. Second column is present the simulation time, the third and forth columns are

the sending and receiving node. While UDP column showing which packet type is used

followed by the packet size, last column present the IP address for the source or

destination with the function of the SIP server.

+ 0.202911 1 2 udp 160 ------- 0 4.0 5.0 0 0 INVITE 0

INVITE 396

- 0.202911 1 2 udp 160 ------- 0 4.0 5.0 0 0 INVITE 0 r 0.207941 1 2 udp 160 ------- 0 4.0 5.0 0 0 INVITE 0 + 0.22303 1 2 udp 160 ------- 0 4.0 5.0 0 0 INVITE 0 - 0.22303 1 2 udp 160 ------- 0 4.0 5.0 0 0 INVITE 0 r 0.22806 1 2 udp 160 ------- 0 4.0 5.0 0 0 INVITE 0 + 0.248095 1 2 udp 160 ------- 0 5.0 4.0 0 1 TRYING 0 - 0.248095 1 2 udp 160 ------- 0 5.0 4.0 0 1 TRYING 0 r 0.253104 1 2 udp 160 ------- 0 5.0 4.0 0 1 TRYING 0 + 208.466495 0 4 udp 577 ------- 0 5.0 4.0 2676 268024 - 208.466495 0 4 udp 577 ------- 0 5.0 4.0 2676 268024 INVITE 396 d 208.471524 0 4 udp 577 ------- 0 5.0 4.0 2676 268024 INVITE 396 + 208.471524 4 0 udp 170 ------- 0 4.0 5.0 2654 268074 TRYING 396 - 208.471524 4 0 udp 170 ------- 0 4.0 5.0 2654 268074 TRYING 396

Figure 4.10: Snapshot of Trace File

The second step to obtain the result is AWK code. AWK code is a tool for

translat +

ing the trace file to numerical result, which contains program written by C+

language, this code is placed in the same directory with the trace file. However, the

AWK file specified with each parameter for example there are four code files used in

this simulation for packet loss, jitter, throughput and delay. Figure 4.11 show the code

lines for packet loss.

66

#This program is used to calculate the packet loss rate. BEGIN { # Initialization. Set two variables. fsDrops: packets drop. numFs: packets sent fsDrops = 0; numFs = 0; } { action = $1; time = $2; from = $3; to = $4; type = $5; pktsize = $6; flow_id = $8; src = $9; dst = $10; seq_no = $11; packet_id = $12; if (from==1 && to==2 && action == "+") numFs++; if (flow_id==2 && action == "d") fsDrops++; } END { printf("number of packets sent:%d lost:%d\n", numFs, fsDrops); }

Figure 4.11: AWK File Code for Packet Loss

Finally, the column result is appeared in the terminal window after the write the

following command in the terminal window ($gawk –f measure-loss.awk out_udp.tr).

From this command the result column are come out in the terminal window. On the

other word, the trace is the input of the AWK file and the out put is one column of

number as show in Figure 4.12.

67

0.000 0.000 0.002 0.000 0.001 0.001 0.001 0.002 0.002 0.000 0.003

Figure 4.12: The Out Put from the AWK File

From the column result, the percentages of packet loss are calculated to show

final result analysis and study all the parameters affection in QoS.

68

CHAPTER 5

RESULT AND EVALUATION

5.1 Introduction

In this chapter, the results which obtained from simulation is analyzed and

discussed to evaluate the performance of VoIP codecs using NS2. The most affected

parameters to QoS in VoIP using SIP server are packet loss, throughput, jitter delay and

end to end delay are analyzed in section 5.2.

5.2 QoS Parameters Analysis

The most affected parameter in the VoIP (ITU) using SIP server are packet loss,

jitter, throughput and end to end delay. Each parameter is analyzed and studied for each

codec with five values of packet size.

69

5.2.1 Packet Loss

Packet loss is a ratio of the number of packets lost to the total number of packets

transmitted (Oliver, 2002). Packet loss occurred when packets sent are not received at

the end destination. However, the percentage of packet loss for different codec technique

at certain operating range is depicted in Figure 5.1 and Figure 5.2.

From Figure 5.1 and Figure 5.2 show that packet loss are occurring in a burst

manner, most of the packet dropped due to of the failure transmission during many

packets accumulated in the queue, if the state of the queue is defined as the number of

waiting packet in the queue, this queuing system is unstable, it will eventually overflow

and start to drop packets by a Drop Tail manner, as it default setting in NS2.

Packet Loss with size 64,128 and 200byte

0

0.5

2

1

1.5

1 2 3 4 5 6 7 8 9 10

Number of Calls

Pack

et L

oss

%

Figure 5.1: Packet Loss for G.711, G.723 and G.729 with 64,128 and 200 Byte

of Packet Size.

G.711 packet=64ByteG.711 packet=128ByteG.711 packet=200ByteG.723 packet=64ByteG.723 packet=128ByteG.723 packet=200ByteG.729 packet=64ByteG.729 packet=128ByteG.729 packet=200Byte

70

VoIP is affected more with the packet loss due to it leads to loss some samples of

voice in the receiver node. From the simulation, with the 64, 128 and 200 Byte of packet

size, G.711 is suffered dramatically from packet loss comparing with G.723 and G.729.

The main reason of packet loss is the packet length and the interval time between two

generated packets which are in G.711, which leads G.711 drops packets especially when

the packet size is 200 Byte with the number of calls 5 to 10.

While G.723 has low percentage of packet loss or can say there is no packet loss

with G.723, the reason is the packet size and the interval time. Between each two

followed packets is 30 ms, which means there is no over load on the queue of routers

and also because of the packet size is a quit small. From that G.723 can handle many

user with many calls as in Figure 5.1 whatever the number of calls and the packet size

were, the G.723 has no packet loss comparing with G.711 and G.729.

With G.729 the packet loss is occur as soon as the number of calls increase but

not high as G.711 and not low as G.723, the reason is G.729 has the same interval time

with G.711 but G.729 has small packet size because it is a low bit rate (high compress).

On the other hand, it has the same packet size with G.723 but the interval time is 10ms

smaller than G.723 that leads to drop packet when the bandwidth is high.

71

Packet Loss with size 512 and 1000byte

0

0.5

2

1

1.5

1 2 3 4 5 6 7 8 9 10

Number of Calls

Pack

et L

oss

%

G.711 packet=512ByteG.711 packet=1000ByteG.723 packet=512ByteG.723 packet=1000ByteG.729 packet=512ByteG.729 packet=1000Byte

Figure 5.2: Packet Loss for G.711, G.723 and G.729 with 512 and 1000 Byte of

Packet Size.

From Figure 5.2 with G.711 and 1000 byte of packet size the packet loss increase

clearly until it reach 2% when the number of calls is 10, while with 512 of packet size

G.711 increase either, similarity with the 1000 distribution but the difference is around

1% from each other that means the affection of packet size is clearly occurred when the

packet size is 1000 byte.

While G.723 still has the same distribution when it can deal with the packet loss

even though the packet size is high and there are 9 of calls the packet loss is 0%.

Definitely, G.723 can deal with the packet loss, can say no packet loss occurred with

G.723 due to its interval time is 30 ms.

G.729 also consider as low packet loss in term of its packet size is low and the

interval time is small, due to the packets in G.729 suffer from the algorithmic delay in

each packet thus that leads low probability to occur over load in the queue then no much

more packet loss.

72

5.2.2 Throughput

The throughput corresponds to the amount of data in bits that is transmitted over

the channel per unit time. Generally the throughput measured in bits per second (bps).

And below is a formula used for calculating the throughput.

Tr = Total packets received at the all received end in one second

R=300 Average throughput = ∑ Tr R=1

The system throughput appears steady because of the frame of transmission in

the NS2 is 155Mbps. The throughput for different codecs system at certain operation

range is shown in Figure 5.3 and Figure 5.4, from these figures, the bandwidth of the

network connection also affects the throughput when consider the number of calls and

the size of the packets. Generally when the number of calls increases, it leads to low

throughput due to link initially become burst and more transmission required.

73

Throughput with packet size 64,128 and 200byte

00.10.20.30.40.50.60.70.80.9

1 2 3 4 5 6 7 8 9 10

Number of Calls

Thro

ughp

ut (b

it/se

cond

)G.711 packet=64ByteG.711 packet=128ByteG.711 packet=200ByteG.723 packet=64ByteG.723 packet=128ByteG.723 packet=200ByteG.729 packet=64ByteG.729 packet=128ByteG.729 packet=200Byte

Figure 5.3: Throughput versus Number of Calls Using Codec G.711, G.723 and G.729

AT 64, 128 and 200 Bytes of Packet Size.

From Figure 5.3, obviously G.711 has a highest throughput comparing with

G.723 and G.729 because of the interval time is shorter than the others codecs when

G.723 and G.29. However, G.711 with the three packet sizes it distributed similarity,

when 1, 2 and 3 calls the throughput increase and take a suitable range from call 4 to 10.

With many calls simulation G.711 transmits many packet due to it generate multiple

packets (no compression) comparing with G.723 and G.729 thus it transmits many bit

per second (high throughput).

Worth to note, G.723 throughput is increasing dramatically along with the

number of calls but it still in low throughput comparing with G.711 and G.729 with the

three packet sizes. The reason is G.723 spend extra 20ms with each packet to send

comparing with G.711, due to its interval time is 30ms and G.711 is 10ms. Furthermore,

G723 generate fewer packets than G.711 because it needs to compress the packet.

74

Clearly to notice from Figure 5.3, that G.729 has the same distribution with

G.711 since they have the same interval time 10ms but the throughput is lower than

G.711 because it has a small packet size to transmit when the packets are under a high

level of compression.

Troughput with packet size 512and 1000byte

00.10.20.30.40.50.60.70.80.9

1 2 3 4 5 6 7 8 9 10

Number of Calls

Thro

ughp

ut (b

it/se

cond

) G.711 packet=512ByteG.711 packet=1000ByteG.723 packet=512ByteG.723 packet=1000ByteG.729 packet=512ByteG.729 packet=1000Byte

Figure 5.4: Throughput versus Number of Calls Using Codec G.711, G.723 and G.729

AT 512 and 1000 Bytes of Packet Size

Figure 5.4 shows G.711 throughput affected by packet size when it set to 512

and 1000 the throughput decreased approximately 0.3 bit/second and 0.4 bit/second for

512 byte and 1000 byte respectively. Worth to notice, the throughput with G.711 with

the two packet sizes is steady whatever whenever the number of calls in change.

However, G.711 still considers the highest throughput comparing with G.723 and G.729.

G.723 because its interval time, it still has a low throughput especially with

small number of calls below 5 calls, but it increase as soon as the number of calls

increase. Clearly G.723 has the lowest throughput and that leads to low band width with

75

it, when there are many users it is a proper choice since it avoiding the over load to the

network.

While G.729 with the two sizes 512 and 1000 byte from Figure 5.4 it still as a

similar distribution with other packet sizes furthermore it looks like G.711 distribution

else G.729 has lower throughput than G.711 since it has high level of compression

which leads G.729 generate little packets.

5.2.3 Jitter

There are many methods to calculate jitter delay in simulations programs, in

this simulation jitter will measured using the following formula (Alias and Ong, 2006):

current packet received time – last packet received time

Jitter = --------------------------------------------------------------------

differential of sequence number between two packet

Jitter is a variation rate in the delay of receiving packets. From Figure 5.5 and

Figure 5.6. Whatever the packet size and the amount of data are, the jitter values dose

not vary much. However, jitter delay for G.723 is higher than G.711 and G.729. when

the small size of the packet are generated and the interval time between packet are vary

thus that leads to increase in the jitter between the packet received. On the other hand,

when the packet size is high with G.711, the jitter will be less significant as a smaller

number of packets generated.

76

Jitter with packet size 64,128 and 200byte

0

0.005

0.01

0.015

0.02

0.025

0.03

1 2 3 4 5 6 7 8 9 10

Number of Calls

Jitte

r (se

cond

)


Figure 5.5: Jitter versus Number of Calls Using Codec G.711, G723 and G.729 At 64,

128 and 200 byte of Packet Size.

Since jitter is depending more with interval time so from Figure 5.5, G.711 and

G.729 have the same value of jitter delay even though the number of calls is high and

the packet size is large.

On the other hand, G.723 with the three sizes in Figure 5.5, G.723 has the higher

jitter delay comparing with G.711 and G.729 the main reason is the interval time

between two following packets when it set in 30ms that is definitely will affect the jitter

with G.723. Thereby, the number of calls from 1 to 10 did not affect the jitter at any

time.

77

Jitter with packet size 512 and 1000byte

0

0.005

0.01

0.015

0.02

0.025

0.03

1 2 3 4 5 6 7 8 9 10

Number of Calls

Jitter

(sec

ond)

G.711 packet=512ByteG.711 packet=1000ByteG.723 packet=512ByteG.723 packet=1000ByteG.729 packet=512ByteG.729 packet=1000Byte

Figure 5.6: Jitter versus Number of Calls Using Codec G.711, G723 and G.729 At 512

and 1000 byte of Packet Size.

With high packet size 512 and 1000 byte from Figure 5.6 comparing with

distribution results from Figure 5.5 however no much worthy change as mention in the

early of this section whatever the packet size and the number of calls have been changed

the jitter has a steady average. Hereby, G.723 only the technique which has highest

jitters due to its interval time is high.

5.2.4 End to End Delay

End to end delay can be classified under two part of delay characteristic,

fixed delay and variable delay. Fixed delay includes packetization delay, propagation

delay and look ahead delay. On the other hand, variable delay includes jitter delay,

queuing delay and network delay.

78

In this project, packetization delay will be chosen to study due to the codec

which have been chosen in this project do the packetization (put the sample of voice in

frames then preparing them as a packet to send via network). As mention in Chapter

two, every codec has its own features to generate a packet thus each codec will behave

different methods from each other, thereby the codec will affect in term of delay

(packetization delay). G.711 has 64 bit rate (high bit rate), that means it creates multiple

packets with small of size, no compression, means no delay for compression leads to fast

transmission ensure low delay but require high bandwidth. In contrast, with the same

packet size presented, G.729 (low bit rate) have to spend 8 times longer than G.711 to

compress before its transmission start, this leads to more delay in voice transmission.

Obviously, low bit rate speech codec typically has longer algorithmic delay and required

much more processing power and time than a high bit rate speech codec. However,

G.723 the small frame size and bigger frame interval, with an end to end delay will

increase in small rate level with number of calls, if the delay is acceptable so G.723

provides a low complexity in stead of G.729 in term of quality of voice. Figure 5.7 and

Figure 5.8 show the end to end delay for each codec.

End to End Delay with packet size 64, 128 and 200byte

0200400600800

10001200140016001800

1 2 3 4 5 6 7 8 9 10

Number of Calls

End

to E

nd D

elay

(ms)


Figure 5.7: End to End delay versus Number of Calls Using Codec G.711,

G.723 and G.729 At 64, 128 and 200Bytes of Packet Size.

79

Obviously, from Figure 5.7 G.711 end to end delay increase along with number

of calls, the main reason is the multi packet which G.711 generates (no compression) by

that no time spend for compression process thus that insure low delay to transmit its

packet but it require high band width for the multi packet, that is why G.711 has a high

quality of voice.

G.723 with the high level of compression, has a low average of delay comparing

with the G.711 and G.729 due to the number of packets are small in G.723 also that

make no high over load on the network so it make the transmission very light.

While G.729 the low bit rate (high compress) consider as highest algorithmic

delay when it spend much more time compress processing. Clearly, from Figure 5.7

G.729 and G.711 are similar in their distribution result but they have different reasons in

delay, G.729 delay because compression delay and G.711 due to the multiple packet

generation.

End to End Delay with packet size 512 and 1000byte

0200400600800

10001200140016001800

1 2 3 4 5 6 7 8 9 10

Number of Calls

End

to E

nd D

elay

(ms) G.711 packet=512Byte

G.711 packet=1000ByteG.723 packet=512ByteG.723 packet=1000ByteG.729 packet=512ByteG.729 packet=1000Byte

Figure 5.8: End to End delay versus Number of Calls Using Codec G.711,

G.723 and G.729 At 512 and 1000Bytes of Packet Size.

80

As soon as the packet size become big G.729 need to spend much more time to

compress this packets, as shown in Figure 5.8 G.729 reaches 1700ms of delay in 10

number of calls, if the quality of voice required so this technique is not recommended,

but if there are many user and heavy data G.729 is the guarantee technique to use.

G.711 the high bit rate then no compress processing happened, low delay

occurred when the number of calls are from 1 to 5, while with 6 calls around 800ms

delay increasing to 1000ms in 8 calls and 1200ms with 10 calls. Since the delay increase

along with call number that shows because of the many generated packets need to

handle.

While G.723 with 512 byte the delay looks like absent even with 10 numbers of

calls, G.723 has low bit rate while that make it generates a light packet format size, all

that caused low band width and low over load on the network, therefore G.723 is a

preferred codec technique when many user are required.

5.3 Discussion

The performance of G.711, G.729 and G.723 from the result in the Chapter 5 is

discussed in this section. For a vary value of packet size with each codec. With all

codecs, there is a high degradation of the capacity of calls with the packet size. With

G.711going from 64bytes to 1000bytes reduce the capacity from 4 calls to 2, while with

G.723 with 9 calls are possible at 64bytes, and 10 calls can be made at 1000bytes. On

the other hand, G.729 is quite similar with G.711 where from 4 calls at 64bytes down to

2 calls at 1000bytes.

81

G.711 is preferred approach since it avoids both delay and data loss, hence have

toll-quality voice. However, this may prove more expensive and use high capacity on

SIP channel especially when packet overhead is taken into account.

Using G.729 as a higher compression speech codec are increasing the number of

channels comparing with G.711. Due to the drop tail queuing affected more with the

number of packets which has to process since G.711 has many packets to be transmit.

Unless a very high voice quality requirement precludes its use, G.729 as low bit

rate codec is shown to allow a capacity greater than or equal to that when G.711 is used,

for a given quality requirement.

However, the low bit rate codecs such as G.723 and G.729 have lower

throughput comparing with G.711 the high bit rate. Hence, G.723 has ability to provide

the highest capacity of VoIP calls, due to its voice packets are little and frequently send

which leads to low throughput in term of packet received. In addition, G.723 has an

ability to deal with packet loss, therefore for a very busy network it will be a proper

choice.

5.4 Conclusion

This chapter come out with the results and evaluation from the simulation which

it has been done using NS2, showing the specific details and overview the parameters

which affect directly to the performance of VoIP using SIP server, and have studied the

QoS for the three codecs G.711, G.723 and G.729, and the selected parameters are

packet loss, jitter, throughput and end to end delay.

82

CHAPTER 6

CONCLUSION

6.1 Conclusion

In this project, the performance of VoIP using NS2 to make a vary number of

calls will be evaluated. Capacity of calls is high affected to the delay, jitter, throughput

and packet loss, and the packet size either, which applied to the chosen speech codecs

using SIP server. Considering ideal channel conditions which has no error. As

conclusion, using G.723 the low bit rate can obtain a high number of calls if many users

required and required low bandwidth, so with G.723, has a best choice to handle many

calls. Throughout, the use of G.729 which is low bit rate codec and a high compression

can also handle a high capacity of calls than G.711 but with low voice quality because

G.729 has a highest value of delay in packetization. On the other hand, G.711 is a

preferred approach when it has a high quality of voice and avoids both delay and data

loss, only if not many calls required because it needs high bandwidth for its multiple

packets.

83

Since the real world environments are not ideal, performance of VoIP mileage

will vary. Hereby, the results of simulation programs do not have a high reality as the

real time environment.

6.2 Future Work

Since this project is revolving around two area which VoIP and SIP server protocol.

Thus, there are two possible topics as future work:

1- Apply the same simulation using WLAN for example applying 802.11x network

technology to see how the same parameters will affect the performance with the

wireless.

2- Apply SIP server protocol between different media communication, it means not

only calls between IP to IP but also ability to call between cellular phone to IP,

or vice versa.

3- Study the performance of same and new parameters when applying VoIP on

mobility or on IPv6 environment.

84

REFERENCES

Adaptive Digital Technologies. (2007). U.S. : Adaptive Digital from :

http://www.adaptivedigital.com.

Advance Waterfall Research Methodology. (1999). Malaysia : Research Methodology

from : www.dspace.fsktm.um.edu.my/bitstream/1812/160/5/Chapter3.pdf

Alias, M. and Ong, L. L. (2006). Performance of Voice over IP (VoIP) over a wireless

LAN (WLAN) for different audio/voice codecs. Malaysia: Universiti Teknologi

Malaysia.

Amrir, M., Tariq, M.and Noor, M.(2005). Evaluation of VoIP Quality over the

Pakistan Internet Exchange (PIE) Backbone. Pakistan.

Christin, N., (2004). Building ns-2 on Cygwin[version 2.27, 2.26, and 2.1b9a(*), UC

Berkeley – School of Information Management and Systems.

Cisco Document Server, “Traffic Analysis for Voice over IP, Posted September 2002.

Daniel, M. and Emma, M. (2002). Delivering Voice Over IP Networks. (2nd Ed). U.S.

: Wiley.

Davis, Y. P. (1993). Digital Audio Compression. A survey: IEEE, Part D. TJA03P8.

INTERNATIONAL TELECOMMUNICATION UNION. (1988). Switzerland:

Geneva.

ITU-T Recommendation G.107. 2003, The E-model, a computational model for use in

transmission planning.

ITU-T Recommendation G.114, 2003, One way transmission time.

ITU-T Recommendation P.59. Artificial conversational speech.

Ixia. (2005). Assessing VoIP Call Quality Using the E-model. CA 91302. Calabasas :

West Agoura Road.

http://www.adaptivedigital.com/

85

Jim, D. and Neil, A. (2006). Internet Phone Services Simplified. U.S.: Indianapolis

Cisco Press.

Jonthan, D. , James, P. , Manoj, B. Satish, K. and Sudipto, M. (2007). Voice Over IP

Fundamentals. (2nd Ed). U.S.: Indianapolis Cisco Press.

Kee,N.T.,Yin,and Moh. (2005). Voice Performance Study on Single Radio Multihop

IEEE 802.1 lb Systems with Chain Topology. Malaysia: Asian Research Center.

Kerry, C. (2006). A Guide to Open Source Audio Streaming. (1st Ed). U.S. : IT

Security Consultant.

Lin, C., Xuemin, S., Jon, W., Lin C.(2005). Voice Capacity Analysis of WLAN with

Unbalanced Traffic.China.

Michele, L.(1996). SIP Module for Network Simulator 2.Italia.

Monroe Street Santa Clara (2000). CA 95051-1450. U.S. : Extreme Networks.

Network Simulator 2. http://www.isi.edu/nsnam.

Oliver, C. I. 2002, Converged Network Architectures, Delivering Voice and Data over

IP, ATM, and Frame Relay.1st edition. United States of America: John Wiley &

Sons, Inc.

Oliver, H. , David, G. and Jean, P. (2000). IP Telephony Packet-Based Multimedia

Communications Systems. U.S. : Pantek Arts, maidstone.

Richard, S. (2002). Comparison of Voice over IP with circuit switching

Techniques. A survey: CiteSeer.ist.

Toral, H. and Torres, D. (2005). Traffic Analysis for IP Telephony. IEEE , 05EX1097.

Mexico: Guadalajara.

VOCAL Technologies. (2007). ITU Recommendation G.711. from:

http://www.vocal.com/data_sheets/g711.html .

What is a VoIP codec ?.(2005). Retrieved on March 1, 2008, from

http://www.tech-faq.com/voip-codec.shtml.

http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-G.711

http://www.tech-faq.com/voip-codec.shtml

86

APPENDIX A

OTcl Simulation Code set N 2 ;#call/sec set simtime 10 set call_time 10 set sip_rate [expr (577 * 8 * $N)] set interarrival [expr (1.0 / $N)] set sip_packet_size 577 set voice_packet_size 160 set voice_burst_time 1.0 set voice_idle_time 1.3 set voice_rate 64000 set tidle 1 set ttotal 2.3 set tmedio [expr (${tidle} / ${ttotal})] set from 1 set to 2 set ns [new Simulator] $ns use-scheduler Heap #Queue set limit_ 10 Trace set show_sctphdr_ 0 Trace set show_tcphdr_ 0 puts "Start simulation with $N Call/sec" # initializations remove-packet-header NV LDP MPLS rtProtoLS Ping RAP AODV SR TORA IMEP Encap HttpInval MFTP SRMEXT set nt [open out_udp.tr w] set nf [open graph.nam w] $ns namtrace-all $nf $defaultRNG seed 0

87

#topology # nodes set LO1 [$ns node] set LO2 [$ns node] set TO1 [$ns node] set TO2 [$ns node] #node of SIP proxy server set PR1 [$ns node] set PR2 [$ns node] set n_voice_($to) [$ns node] set n_null_($to) [$ns node] set n_voice_($from) [$ns node] set n_null_($from) [$ns node] #node of voicetest set n_test_1 [$ns node] set n_test_2 [$ns node] set WEB2 [$ns node] #link $ns duplex-link $TO1 $TO2 155Mb 5ms DropTail $ns duplex-link $LO1 $TO1 155Mb 5ms DropTail $ns duplex-link $TO2 $LO2 155Mb 5ms DropTail $ns duplex-link $PR1 $LO1 155Mb 20ms DropTail $ns duplex-link $PR2 $LO2 155Mb 20ms DropTail $ns duplex-link $LO1 $n_voice_(1) 155Mb 20ms DropTail $ns duplex-link $LO1 $n_null_(1) 155Mb 20ms DropTail $ns duplex-link $LO2 $n_voice_(2) 155Mb 20ms DropTail $ns duplex-link $LO2 $n_null_(2) 155Mb 20ms DropTail $ns duplex-link $n_voice_(1) $n_test_1 155Mb 0ms DropTail $ns duplex-link $n_null_(2) $n_test_2 155Mb 0ms DropTail #------------------------------------------------------------------- #agent test for voice sources set udp_test [new Agent/UDP] $udp_test set class_ 2 $ns attach-agent $n_test_1 $udp_test $ns trace-queue $n_test_1 $n_voice_(1) $nt #agentTestSink set udp_test_sink [new Agent/Null] $ns attach-agent $n_test_2 $udp_test_sink $ns trace-queue $n_null_(2) $n_test_2 $nt #proxy set udp_1 [new Agent/UDP/UDPSIP]

88

$ns attach-agent $PR1 $udp_1 $ns trace-queue $PR1 $LO1 $nt $ns trace-queue $LO1 $PR1 $nt set udp_2 [new Agent/UDP/UDPSIP] $ns attach-agent $PR2 $udp_2 $ns trace-queue $LO2 $PR2 $nt # connects peers $ns connect $udp_1 $udp_2 $ns connect $udp_test $udp_test_sink #------------------------------------------------------------------- #applications: 2 Proxy servers set sip_1 [new Application/Traffic/SipUdp] $sip_1 set packetSize_ ${sip_packet_size} $sip_1 set burst_time_ 0 $sip_1 set idle_time_ interarrival $sip_1 set rate_ 2.5Mb $sip_1 set print_ 0 $sip_1 set minSS7delay_ 0.025 $sip_1 set maxSS7delay_ 0.05 $sip_1 set end_call_management_ 1 $sip_1 set call_min_ 90 $sip_1 set call_max_ 120 $sip_1 set from_ $from $sip_1 set to_ $to $sip_1 set codecselector_ 0 $sip_1 set siptimer_ 0 $sip_1 attach-agent $udp_1 set sip_2 [new Application/Traffic/SipUdp] $sip_2 set packetSize_ ${sip_packet_size} $sip_2 set burst_time_ 0 $sip_2 set idle_time_ interarrival $sip_2 set rate_ 2.5Mb $sip_2 set print_ 0 $sip_2 set minSS7delay_ 0.025 $sip_2 set maxSS7delay_ 0.05 $sip_2 set end_call_management_ 1 $sip_2 set call_min_ 90 $sip_2 set call_max_ 120 $sip_2 set from_ $to $sip_2 set to_ $from $sip_2 set codecselector_ 0 $sip_2 set siptimer_ 0 $sip_2 attach-agent $udp_2 #Test voice source set voice_test [new Application/Traffic/Exponential] $voice_test set packetSize_ $voice_packet_size ;#132 $voice_test set burst_time_ $voice_burst_time ;#1000ms $voice_test set idle_time_ $voice_idle_time ;#1300ms $voice_test set rate_ $voice_rate ;#16k $voice_test attach-agent $udp_test #---------------------------------------------------------

89

source udp_utils.tcl # finish procedure proc finish {} { global ns nt nf $ns flush-trace close $nf close $nt exec nam graph.nam & exit 0 } #--------------------------------------------------------- #scheduler set fintime [expr $simtime + $call_time] $ns at 0.0 "$sip_1 start" $ns at 0.0 "$sip_2 start" puts "start_sip" $ns at 0.0 "$voice_test start" $ns at $fintime "$voice_test stop" $ns at $simtime "$sip_1 stop" $ns at $simtime "$sip_2 stop" $ns at $fintime "finish" $ns run

90

APPENDIX B

Overview Tables for Over All the Results Which Are Obtained from Trace File.

Table 1: Overview of Packet Loss for Codec G.711

G.711 Number of

Calls 64 Bytes 128 Bytes 200 Bytes 512 Bytes 1000 Bytes

1 0.00 0.00 0.00 0.04 0.15

2 0.00 0.00 0.08 0.02 0.24

3 0.13 0.14 0.08 0.39 0.65

4 0.14 0.18 0.44 0.24 0.79

5 0.15 0.23 0.33 0.44 0.77

6 0.22 0.35 0.58 0.72 1.05

7 0.27 0.39 0.66 0.86 1.26

8 0.29 0.45 0.81 0.96 1.42

9 0.33 0.48 0.91 1.02 1.61

10 0.39 0.54 1.22 1.24 1.79


G.723 Number of


1 0.000 0.000 0.000 0.000 0.000

2 0.000 0.000 0.000 0.000 0.003

3 0.000 0.000 0.000 0.000 0.002

4 0.001 0.001 0.000 0.000 0.003

91

5 0.004 0.000 0.000 0.000 0.08

6 0.000 0.000 0.000 0.132 0.194

7 0.003 0.000 0.011 0.098 0.141

8 0.002 0.028 0.013 0.108 0.211

9 0.062 0.002 0.069 0.004 0.234

10 0.000 0.001 0.077 0.135 0.664


G.729 Number of


1 0.000 0.007 0.139 0.000 0.000

2 0.001 0.106 0.017 0.172 0.193

3 0.084 0.244 0.251 0.091 0.357

4 0.111 0.183 0.259 0.393 0.397

5 0.281 0.205 0.254 0.382 0.565

6 0.086 0.304 0.337 0.266 0.645

7 0.452 0.309 0.348 0.605 0.703

8 0.268 0.476 0.591 0.431 0.972

9 0.436 0.519 0.597 0.781 0.907

10 0.458 0.649 0.509 0.781 1.066

Table 4: Overview of Throughput for Codec G.711

G.711 Number of


1 0.268 0.276 0.264 0.261 0.266

2 0.541 0.518 0.515 0.492 0.382

3 0.731 0.715 0.681 0.531 0.386

4 0.767 0.759 0.702 0.531 0.388

5 0.772 0.772 0.704 0.533 0.387

6 0.771 0.771 0.701 0.533 0.386

7 0.762 0.765 0.695 0.522 0.385

8 0.758 0.759 0.69 0.523 0.383

9 0.755 0.751 0.688 0.521 0.381

10 0.744 0.743 0.682 0.522 0.382

92


G.723 Number of


1 0.046 0.046 0.045 0.047 0.043

2 0.091 0.091 0.092 0.088 0.097

3 0.134 0.134 0.135 0.137 0.131

4 0.182 0.175 0.173 0.179 0.179

5 0.224 0.219 0.221 0.217 0.217

6 0.271 0.258 0.267 0.265 0.238

7 0.306 0.312 0.315 0.286 0.247

8 0.365 0.361 0.354 0.313 0.251

9 0.381 0.387 0.367 0.312 0.249

10 0.405 0.406 0.385 0.321 0.251


G.729 Number of


1 0.139 0.146 0.129 0.137 0.134

2 0.256 0.267 0.248 0.219 0.195

3 0.307 0.314 0.303 0.258 0.207

4 0.328 0.328 0.321 0.263 0.208

5 0.334 0.333 0.327 0.263 0.209

6 0.334 0.334 0.326 0.262 0.208

7 0.333 0.333 0.325 0.251 0.208

8 0.331 0.332 0.325 0.259 0.206

9 0.328 0.328 0.321 0.256 0.205

10 0.327 0.327 0.322 0.256 0.204


G.711 Number of


93

1 0.004 0.004 0.004 0.004 0.004

2 0.004 0.004 0.005 0.005 0.006

3 0.005 0.005 0.005 0.007 0.008

4 0.006 0.006 0.006 0.008 0.008

5 0.007 0.007 0.007 0.007 0.008

6 0.007 0.008 0.008 0.008 0.009

7 0.008 0.008 0.007 0.009 0.009

8 0.008 0.008 0.008 0.008 0.009

9 0.008 0.009 0.009 0.009 0.011

10 0.011 0.009 0.009 0.009 0.012

Table 7: Overview of Jitter for Codec G.723

G.723 Number of


1 0.021 0.021 0.021 0.021 0.023

2 0.021 0.021 0.021 0.023 0.021

3 0.021 0.022 0.023 0.022 0.022

4 0.022 0.023 0.023 0.021 0.022

5 0.023 0.022 0.023 0.023 0.022

6 0.022 0.023 0.022 0.022 0.024

7 0.023 0.022 0.022 0.023 0.025

8 0.022 0.021 0.022 0.022 0.024

9 0.022 0.023 0.023 0.023 0.025

10 0.023 0.022 0.022 0.024 0.026

Table 8: Overview of Jitter for Codec G.729

G.729 Number of


1 0.005 0.005 0.006 0.005 0.005

2 0.006 0.006 0.005 0.007 0.006

3 0.007 0.006 0.006 0.006 0.007

4 0.006 0.006 0.007 0.006 0.008

5 0.006 0.006 0.006 0.007 0.008

94

6 0.006 0.006 0.007 0.007 0.009

7 0.006 0.006 0.006 0.007 0.007

8 0.007 0.006 0.006 0.008 0.008

9 0.007 0.007 0.006 0.008 0.009

10 0.007 0.007 0.006 0.009 0.009

Table 9: Overview of End to End Delay for Codec G.711

G.711 Number of


1 6.25 6.09 6.47 10.1 75.3

2 23.7 23.7 40.2 170 461

3 128 118 180 399 761

4 214 203 303 603 1000

5 392 382 494 803 1271

6 567 567 691 1027 1556

7 701 703 850 1227 1793

8 872 851 982 1389 2035

9 1012 1013 1132 1603 2040

10 1197 1167 1302 1788 2548


G.723 Number of


1 30 30 29 29 32

2 30 31 33 32 32

3 31 32 35 33 36

4 32 33 37 34 55

5 33 34 38 40 118

6 34 33 44 79 185

7 42 41 50 109 254

8 62 62 88 166 322

95

9 95 96 113 200 475

10 125 125 155 221 836


G.729 Number of


1 14 14 20 49 114

2 87 112 104 168 272

3 174 186 205 309 465

4 254 274 284 407 584

5 385 365 404 537 761

6 468 464 482 672 931

7 541 554 614 731 1044

8 688 654 702 945 1254

9 791 771 841 1091 1494

10 891 909 955 1294 1664

Below the plot graph of receiving packet (throughput) with 64 byte of packet size:

96

Throughput of Codec G.711 with 64 Packet Size.



performance analysis of voice codec for voip

Documents