Challenges in VoIP Systems - Mostafa Ahmed Mostafa El Beheiry - First Draft Final

Media Engineering and Technology Faculty
German University in Cairo
Challenges in VoIP Systems
Bachelor Thesis
Author: Mostafa Ahmed Mostafa El Beheiry
Supervisors: Dr. Hisham Hassaballah Othman
Submission Date: 3 June, 2014

This is to certify that:
(i) the thesis comprises only my original work toward the Bachelor Degree
(ii) due acknowledgement has been made in the text to all other material used
Mostafa Ahmed Mostafa El Beheiry
3 June, 2014

Acknowledgments
I would like to acknowledge the following people and institutes whom have been instru-
mental in how this work turned out. Who kept me motivated and enthusiastic to work
throughout the entire span of the work.
Before anything I would like to thank God Almighty, for everything.
Dr. Hisham, for guiding me through this work, accepting it as my own work and allowing me to
express it as I envisioned it and not holding me back from putting in as much in it
as need be.
I may have disagreed with some things we discussed and planned to do or not to do,
but I thank him for his understanding that my disagreements were purely academic
and only had the interest of this work in mind.
I would also like to thank Dr. Hisham for the vision he has about VoIP Systems
and how important they are to advance in this country, and in turn giving me the
opportunity to be a building block and hopefully beneﬁt humanity in our never
ending quest for science.
Ahmed Khaled, for his work on VoIP using Java, we explored this thing together and uncovered
the magics that make it work together, and without your work I would not have a
trustworthy application for my simulation.
I thank him for calling me day by day, keeping me up to date with his exploits and
for understanding all the point of criticism I leveled at his work.
The days we spent on the ﬁxing the server were some of the most frustrating and
memorable days I’ve ever spent of a project, but we pulled through somehow, and
thanks for letting me and helping me attack your work for my simulation!
My Parents, for providing me with whatever I asked for the sake of knowledge, for believing in
me and knowing that I can make use of every single penny spent on my educational
life. I can’t begin to express the gratitude. And thanks for giving me a multitude
of solutions to overcome the lack of electricity in these trying times. I love you guys
from the bottom of my heart!
Riot Games, for giving me a way out of the stresses of life by playing League of Legends.
Valve, for making a better game than Riot.
III

Abstract
The remarkable advancement of VoIP Systems in the previous decades made possible what
was thought to be fiction. But with great prgress come great challenges, the development
of VoIP Systems is no different. This work is a collection, categorization and examination
of some of VoIP’s greatest challenges. This work has identified four main categories of
issues, Security, Quality, Dependency, Emergency and how they came to be during the
development of VoIP Systems. Their impact on Voice over IP (VoIP) Systems, whether
or not these issues are crippling to VoIP Systems. Included also are illustrations of the
various issues, for visualization purposes. A real time simulation of a singled out issue
is also included in this work. Finally, this work will also look into possible solutions if
present, or suggest solutions if the issues mentioned do not possess a certain, industry-
standard solution.
Certain topics amongst the four categories have been singled out as the most im-
portant, and will be the focus of this work. As for the Security category all of, Packet
Sniffers, Distributed Distributed Denial of Service (DDoS) Attacks, Eavesdropping, Spam
over IP Telephony (SPIT) Attacks, Difficulties with Firewalls and Operating System and
Network, have been the focus. Concerning Quality the issues of, Bandwidth, Codecs,
Queuing, and Low-Speed Links, will be discussed.
Collaboration has taken place with colleague Ahmed Khaled Saeed Metwally, in cre-
ating a simulation of a SPIT attack using his own implementation of a VoIP Client as a
base [11], and using OfficeSIP as a server.
IV

Contents
Acknowledgements III
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Aim of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Background 4
2.1 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 SIP Invite Request . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Message Method Extension . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Real Time Protocol (RTP) . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Network Address Translators (NAT) . . . . . . . . . . . . . . . . . . . . 11
2.5 VideoLAN Client (VLC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Own Work 13
3.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Packet Sniﬃng . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3 Distributed Denial of Service (DDoS) . . . . . . . . . . . . . . . . 19
3.1.4 Spam over IP Telephony (SPIT) . . . . . . . . . . . . . . . . . . . 21
3.1.5 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.6 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.4 Low Speed Links . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.1 Power Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.2 Internet Dependacy . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Emergency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
V

4 SPIT Simulation 41
4.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Failed Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 OfficeSIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.2 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Conclusion and Future Work 52
5.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.1 Packet Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.2 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.3 DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.4 SPIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.5 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.6 OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.2 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.3 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.4 Low Speed Links . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.2 Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4 Emergency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5 Last Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Appendix 60
A Lists 61
List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B Code 67
C Illustrations 71
References 78
VI

Chapter 1
Introduction
Long distance communication has come a long way since the days of Samuel Morse, and
his 1835 invention of the Morse Code. An invention which Morse used to develop the
worlds first long distance means of communication, the Electric Telegraph Line. 41 years
later humanity saw its second leap, as Scottish inventor Alexander Graham Bell along
with his assistant Thomas A. Watson unveiled the first electric telephone in Boston.
1969 however would see the most significant leap humanity has taken in progressing long
distance communication, as Advanced Research Projects Agency Network (ARPANET)
deployed and managed to successfully connect its first hosts.
While VoIP does not trace its lineage back to a single historic event, it did inherit
fundamental weaknesses from all of its ancestors. Issues of Security passed down from
the telephone are present, as well as issues of Quality introduced from its usage of the
Internet. However, issues passed down such as these are not the only concern for VoIP
Systems, certain Dependencies along with the absence of a way to place an Emergency
Call are all challenges VoIP Systems are faced with if they are to progress as the prime
method of long distance communication.
1

CHAPTER 1. INTRODUCTION 2
1.1 Motivation
Since the early 2000s VoIP Systems have seen major developments, and major widespread
usage. Since then, efforts were made into reviewing and refining VoIP systems, countless
papers have been written detailing flaws, suggesting solutions, or merely documenting
the development of said VoIP Systems. So far however, none has attempted to be com-
prehensive. This work attempts just that, to become a reference point for future works,
to provide a basis on which further research can be made and further developments can
be ensued.
As humanity transitions into the late 2010s, the need for such a work grows, a docu-
mentation of what has come to pass, a reference point for future studies, and a basis for
future work is what this paper has been written to become.

CHAPTER 1. INTRODUCTION 3
1.2 Aim of Work
This Thesis does not claim to solve a single speciﬁc challenge facing VoIP Systems, but
rather attempts to raise multiple questions, discuss them and their probable solutions.
Challenges of VoIP Systems, aims to categorize these challenges into four major cat-
egories which will be discussed. Ordered by the most to least impact, which will be
discussed, the categories are Security, Quality, Dependency, and Emergency.
The Security issues which will be discussed in this work are six, the Quality issues
four, the Dependency three and a single Emergency issue will be discussed. Section 4 is
divided into four chapters, each tackling a category as described above. Each chapter is
divided into as many subsection as there are topics to be discussed. As for how the topics
will be discussed, each topic will contain four major points of discussion. The origin of
the issue, and how it came to be during the development of VoIP Systems. Its impact on
VoIP Systems, the extent of how crippling it can be to a VoIP System, which is also its
importance. Solvability, whether or not this problem has been solved, can be solved, or
even merits a solution. In the case of there not being a solution, and the issue meriting
one, a solution will be proposed.
The six Security issues this work will focus on are, in no particular order; Packet Snif-
fers, Distributed DDoS Attacks, Eavesdropping, SPIT Attacks, Diﬃculties with Firewalls
and Operating System and Network.
The four Quality issues discussed are, Bandwidth, Codecs, Queuing, and Low-Speed
Links.
The three Dependencies in question are, Power Dependency, Internet Dependency,
and Bandwidth Dependency.
A single issue under the Emergency chapter would be, the ability to place Emergency
Calls. Which is a real concern if VoIP systems are to be considered as a real replacement
for modern day telephones.

Chapter 2
Background
The most notable work around the subject matter of Challenges in VoIP Systems as a
general whole subject, would be Hughes Systique Corporations VoIP [9] and its challenges.
Which focused further on the challenges facing VoIP Systems during its deployment phase.
Spoke of some security issues such as NAT and Firewall Traversal. Tackled Quality of
Service (QoS) briefly in a single, two paragraphed page containing 294 words[9, p. 7].
Which by all stretches of imagination is not deep enough for such an issue. It also went
on to focus its efforts on SPIT.
Although a much more in depth, concentrated and well-rounded effort has been made
by Fraunhofer Institute for Secure Information Technologys Rachid El Khayari. His own
work of SPAM over Internet Telephony and how to deal with it, has heavily influenced
this own works section concerning the subject matter[10].
DDoS, has been worked on in the title Evaluating DoS Attacks Against SIP-Based
VoIP Systems written by the collaborated efforts of M. Zubair Rafique, M. Ali Akbar
and Muddassar Farooq. The authors themselves have stated; ”The purpose of our study
is to help both VoIP vendors and academia better understand different vulnerabilities in
the existing SIP servers and how adequately they are protected against them.”[15, p. 1]
Their study however, did not include a solution to DDoS attacks, since the focus of their
paper has been merely the Evaluation of DDoS attacks.
Challenges in Securing Voice over IP and Top Ten Security Issues VoIP, covered the
remainder of the topics adequately and have been extensively read before attempting this
paper [17].
What follows is an explanation of any and all technologies used in this paper, detailing
all the relevant information used from these technologies.
4

CHAPTER 2. BACKGROUND 5
Figure 2.1 Details most of the technologies which will be discussed in this section
along with the relevant issues for which each technology is linked. Also Wireshark and
VLC, which are softwares, have been mentioned in this chapter as they were used in a
few speciﬁc issues. The VoIP Server used has been discussed further in section 4.1.
Figure 2.1: Technologies and Issues (Security)

2.1 Session Initiation Protocol (SIP)
As mentioned above, only relevant to this work information about Session Initiation
Protocol (SIP) will be discussed.
Developed by Internet Engineering Task Force (IETF), it acts as the primary core for
VoIP Systems[16]. Of which many variants have been derived with the aim and goal of
further developing the protocol beyond its weaknesses.
It is a signaling protocol, its tasks are restricted to initiating, maintaining, and closing
the VoIP Call. It has become an industry standard which becomes its greatest strength
and weakness. Strength, in that any SIP based client can communicate with another SIP
based client disregarding most hindering factors. Weakness, in the fact that anyone can
manipulate or extract information from most SIP packets, valuable information at that.
Two of the greatest oﬀenders of this weakness are the Invite Request, and the Message
Method. These will be extensively referenced in the coming chapters thus an explanation
of them is due.
2.1.1 SIP Invite Request
Figure 2.2: Sip Invite Request
The above code snippet in Figure 2.2 details the actual format of SIPs invite request
taken from IETFs own documentation of SIP.[16, 11] What is primarily a concern in this
work is the fact that this request contains the IP Addresses of the person receiving the
call and the person initiating it. It also shows the version of SIP used, the transportation
protocol used and the server handling the call.
The availability of these facts in the Invite Request is an important fact to take into
consideration for the coming chapters, as most of the weaknesses of SIP lay in the fact
that information such as this is readily available.

2.1.2 Message Method Extension
Added to SIP in 2002 [2], this is how SIP handles chat where possible, whether it be a
VoIP application such as Skype with a text chat feature, or an internal company system
with VoIP phones with SIP Messaging Service (SMS) enabled.
Since SIP is in nature a signaling protocol as mentioned is section 2.1, it can only
ever send request or response messages, the extension handles messaging in a way IETF
described as; ”using a metaphor similar to that of a two-way pager or SMS enabled
handset” [2, 2]
Hence, staying true to SIPs nature, the way Instant Messaging (IM) is done is by
sending a request using the Message Method which contains the deliverable message in
the body of the Request Message sent. Also, since it is a Request Message the receiver
must reply with a Response Message.
2.1.3 SIP Codes
The following are tables of the response codes used by SIP as taken from the IETF
Documentation. Some codes have been removed for sake of remaining concise to the
goal. Continued on page 8
1xx Provisional
100 Trying
180 Ringing
199
Early
Dialog Terminated
Table 2.1: Provisional SIP Codes
2xx Successful
200 OK
202 Accepted (Deprecated)
204 No Notiﬁcation
Table 2.2: Successful SIP Codes

3xx Redirection
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service
Table 2.3: Redirect SIP Codes
4xx Request Failure
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
494 Security Agreement Required
Table 2.4: Failure SIP Codes
5xx Server Failure
500
Server
Internal Error
501
Not
Implemented
502
Bad
Gateway
503
Service
Unavailable
504
Server
Time-out
Table 2.5: Server Failure SIP Codes
6xx Global Failures
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable
Table 2.6: Global Failure SIP Codes

2.2 Real Time Protocol (RTP)
2.2.1 Packet Format
This section will be referred to later in the Bandwidth subsection of the Quality section.
A single Real Time Protocol (RTP) packet contains header fields which hold speech
sample time stamps along with sequence numbers and identify each voice packets con-
tents. The content fields however define the compression technique used.
Figure 2.3: RTP Packet
This packet is left unchanged on most protocols, aside from the edge header and
trailer which vary. The Digitized voice, RTP Header, User Diagram Protocol (UDP)
Header along with the IP Header remain unchanged.
The Ethernet Trailer is present to detect errors, while the Ethernet Header holds the
Local Area Network (LAN) Media Access Control (MAC) addresses of the devices it is
being transferred to and from. The IP Header holds the to and from IP Adresses along
with some control information. The UDP Header carries the portnumbers of the sending
and receiving devices. The digitized voice filed can carry anything from 10 to 320 bytes
of voice[18].

2.3 Wireshark
The Open Sourced nature of Internet development has made a tool such as Wireshark
available, primarily it functions as a traffic analysis tool, but its abilities go much further
than just that.
Its core function is capturing all traffic flowing in and out of a certain gateway/com-
puter/target device, for instance a simple capture of Wireshark on a certain computer
would reveal the packets being sent to and from that computer. With the luxury of most
of the industry standard protocols being open sourced, such as SIP, Wireshark has been
able to integrate a truly deep method of inspecting each and every packet rushing along
its target device.
It is a Multi-platform program, meaning it is available to the vast majority of users,
by which this means it is available to Windows, Linux, OS X, Solaris users amongst
others. Boasting filters for over a hundred protocols one could argue it is too powerful a
tool to be put, free of charge, to this vast majority of users.
Amongst the features it boasts to possess is a ”Rich VoIP analysis” meaning it is
especially capable in this field. Aided by the ability to capture a stream of data and not
only play but output the capture to a number of different formats after being compressed.
Also it boasts to be able to capture traffic and output the capture to another network
analysis tool, making it more flexible than any other choice in the industry[4].
Figure 2.4 shows an actual capture taken by Wireshark of a UDP Packet.
Figure 2.4: SCCP UDP Packet Capture

2.4 Network Address Translators (NAT)
Network Address Translators (NAT) was created as a countermeasure to delay the im-
pending depletion of IPv4 addresses, it functions by allowing for IP Address reuse through
a router function. This occurs by dividing the networks into a stub for which the router
can assign the same addresses assigned in other stubs.
Figure Figure 2.5 depicts an operational network in which NAT is used, as is taken
from the IETF Documentation. [6]
Figure 2.5: NAT Operaction

2.5 VideoLAN Client (VLC)
VLC originally began as a client for streaming videos over a network. A product of Ecole
Centrale Paris students and began as a purely academic endeavor is now a media player
managed by the VideoLAN Non-proﬁt organization. Amassing over 1.3 billion downloads
for Windows and OSX alone[19].
It is arguably the strongest media player in the industry, in which it does not simply
retrieve a ﬁle from the Hard Disk Drive (HDD). The various methods of input are its
greatest strength and above all the various ways in which it can receive content is what
truly makes it stand out.
The windows version for instance can play a video using the following protocols: UD-
P/RTP Unicast, UDP/RTP Multicast, Hypertext Transfer Protocol (HTTP)/File Trans-
fer Protocol (FTP), Multimedia Messaging Service (MMS), Transmission Control Proto-
col (TCP)/RTP Unicast, File on HDD, Digital Video Disc (DVD), Video CD (VCD),
Super VCD (SVCD), Audio CD, Digital Video Broadcasting (DVB) (Satellite), Digitale
TV, Cable TV, Motion Pictures Experts Group (MPEG) Encoder, Video Acquisition
(Direct Show).
For a show of its strength in playable formats, all of the following can be played on
all of the Windows, OS X and Linux versions: MPEG, Audio Video Interleave (AVI),
Advanced Systems Format (ASF)/Windows Media Video (WMV)/Windows Media Audio
(WMA), MPEG 4 (MP4)/QuickTime File Format (MOV)/Third Generation Partnership
Project (3GP), Ogging (OGG)/OGG Movie (OGM)/Annodex, Matroska Video (MKV),
Real, Waveform Audio File Format (WAV), Raw Audio, Raw DV, Free Lossless Audio
Codec (FLAC), Flash Video (FLV), Material eXchange Format (MXF), Nut, Musical
Instrument Digital Interface (MIDI)/Standard MIDI File (SMF), CreativeTM Voice.
Figure Figure 2.6 details on what versions are these features available
Figure 2.6: Input Media and Formats of VLC

Chapter 3
Own Work
The following details this own works attempt at gathering and developing information
about the four categories of challenges facing VoIP Systems. First a brief introduction
to this chapter to talk again about these four categories and why they were chosen.
Security, the simplest, most obvious decision. Many of the issues facing VoIP systems
fall under this category, this is due to its inheritance coming from the very first form of
long distance communication to the modern day telephone and the advancement of the
Internet.
Quality, if you are sure your call is one hundred percent secure, yet you cannot hear
or make sense of the audio stream you are receiving then the call is as flawed as if it was
not secure. Perhaps even more so, quality issues come right after security and owe all
their existence to how the Internet has developed.
Dependency, during a power-cut the traditional telephone is still usable, so long as
the call centre that is being connected to remains intact. However, VoIP Systems find
themselves much more reliant on electricity than the telephone. As far as the development
of this particular dependency has come it is still not worked out completely as of yet.
Emergency, admittedly consisting of only the issue of emergency calls, it is an under-
valued challenge which needs to be looked at more than it has been given effort. Virtually
no papers in the field have been written with the goal of addressing this issue, which is
surprising since this is a great disadvantage to using a VoIP System at office or in Mobiles
over relying on traditional systems.
As mentioned in section 1.2, the issues are more than the ones mentioned in this
paper, and hence there will be justification as to why each issue was chosen, this would
also be a suitable time to explain further the structure of each issue and how it will be
dealt with.
Origin, of the issue will be the first focal point of discussion, in many papers the issues
are directly talked about with little mention of how they came to be. Which helps in
understanding why the issue is there, and how it can be dealt with, the age old adage of
13

CHAPTER 3. OWN WORK 14
”History Repeats itself” is true even when computer science is concerned. Learning from
our past can make the future all that much clearer.
Impact, for an issue to qualify as one that needs discussion its impact needs to be
stated, for instance if a DDoS attack can render a call un-place able then it is an issue of
severe magnitude. However if some Echo in the call makes it difficult to understand this
is less of a major concern. It is still a concern which affects the quality of the service, but
it is not as concerning as the service being up altogether. To further seek consistency in
how this variable will be measured, comparisons to the telephone and the mobile phone
(current industry standard) will be drawn.
Solvability, this paper has stated its intention of becoming more of a point of reference
and a base over which future studies could be placed, and this part of the discussion is
essential to this goal. The issues chosen were done favoring the impact of the issue on
VoIP Systems, regardless of whether or not this issue has been solved or not. If the issue
has been solved under a credible reference it will be mentioned, if not then a suggestion
on how it could be solved will be written. If the solution exists but is controversial
then both conditions will occur, hence these are not mutual exclusive conditions. The
Solvability section could mention both a present solution and a proposed better one,
along with a comparison and contrast of both solutions. However, whether or not the
solutions mentioned should be attempted will be discussed in the last section.
Figure 3.1 displays how this chapter, and all its subsections will be organized, each
main category consisting of, Security, Quality, Dependency and Emergency, will have a
subsection of issues. Taking the security for example, the first issue of Packet Sniffers
will be discussed under the aforementioned titles.
Figure 3.1: Organization of Challenges

3.1 Security
VoIP Systems have regrettably inherited much of the flaws of all its predecessors, where
electric telegraphs and Morse Code messages could be intercepted along their route and
interpreted, so too could SIP Messages be intercepted and as mentioned in Sections 2.1.1
and 2.1.2, these messages contain much and more than what a telegraph could have
contained. As any person tapping into a telephone central could monitor the calls of a
certain telephone, so could VoIP Traffic be hijacked and played over a program such as
VLC.
The similarities between flaws of both systems are staggering and many, but the
methods of defending against them vary from issue to issue, as will be explained herein.
3.1.1 Packet Sniffing
Origin
For a packet to set out from its source and reach its destination it needs to pass by
many nodes and stops in along the way. Similarly a phone call needs to pass through the
cables, to the Call Centre and to the callee. Packet Sniffing has its roots from tapping
into phone calls, as someone would tap into the call centre and monitor any calls coming
from a certain line or to a certain line. The person tapping into the phone call could
listen to the phone call as if they were an invisible participant in the call.
This implies many things in case of tapping, the person doing the tapping has now
heard the phone call, and knows whatever information has been exchanged during that
conversation.
The same is viable to do using Wireshark, which as explained has the necessary toolkit
to monitor all incoming and outgoing traffic over a certain device. And as mentioned
before in Sections 2.1.1 and 2.1.2, this means that a simple run of Wireshark can, and
will display the SIP Packets being sent from the caller to the callee, but unlike tapping,
the information in these two packets is more delicate.
While Packet Sniffing does not immediately allow for the intruder to know what is
being said in the VoIP Call, it contains the IP Addresses of both the caller and the callee,
which could be used in a cornucopia of malicious ways.
Also, as stated in 2.1.2, SIPs IM packets contain the message to be delivered in a very
exposed position, which can easily be retrieved by the intruder. Making it merely a case
of attaching Wireshark to any node from the caller to the callee.

Impact
Figure 3.2: SIP Invite Request, as captured by Wireshark
Figure 3.2 [8] shows an actual SIP Invite Request packet captured using Wireshark, and
immediately the magnitude of the issue is made obvious. The IP Address of 107 along
with the IP Address of 101 are known using the two consecutive lines of From and To.
Also the Via line shows the last hop the packet took in order to reach its destination,
allowing for further abuse of the network, and how it is set up.
In Section 2.1.3 the various SIP Response Codes were noted, and since SIP is a
signaling protocol the Invite Request needs a Response. However, the response will also
be sniffed, and the sniffer would now know not only who attempted to call who, but the
state of the callee depending on the response code which is sniffed.
Moreover, the Message Method, which is SIPs own way of handling IM as was men-
tioned in Section 2.1.2, can be sniffed and immediately the chat would become apparent
to the intruder. An argument could be made that this is not worrisome in VoIP Systems
since they are primarily focused with Voice, but many newer systems come with SMS
Enabled devices, and in the case of Skype, it is built around the notion of chatting in the
first place.
The reason why Packet Sniffing is placed amongst the highest on the impact charts is
simple. If a call is denied, as in the case of DDoS, there is no information leaked. If a call
is breached however, this is another matter entirely. The only real argument that could
be made is for Eavesdropping as a contender for the most impactful security breech, but
Eavesdropping is merely an afterthought of Packet Sniffing, Eavesdropping in on its own
does not reveal IP Addresses nor reveal chat messages, and hence Packet Sniffing was
ranked higher.

Solvability
Coming back to the argument of line tapping, and to the adage of looking to the past.
How did our predecessors solve the issue of line tapping, the answer to this question lies
in many ways. To stop a person from tapping into a telephone line at the telephone
centre, it would seem easier to restrict access of people with no security clearance in said
centre. Another solution for those who thought they were under surveillance and did not
want anyone to know what they were saying was to speak in cyphers, hence the content
of the call might be stolen but the thief would not understand it to use it.
Case in point, a solution akin to the first one mentioned above would be to stop any
and all access to the network, which becomes increasingly difficult the bigger the network
grows and the more people begin using it. Hence a further security measure could be
added, speak in cyphers. Or rather, encrypt the SIP packets so they would not be as
easy to gain access to their contents.
Secure SIP (SIPS) aims to do just that, to correct the security flaws of SIP, instead
of sending packets of UDP and TCP. It uses Transport Layer Security (TLS) which is a
newer iteration of Secure Sockets Layer (SSL).
There is however a flaw with this solution, there is a trade-off between security and
availability which must be understood. What makes SIP popular is its compatibility with
all systems, in order to begin using SIPS there arises a need to make sure the devices in
question are compatible with it.
Figure 3.3: A Much more complicated SIPS message

3.1.2 Eavesdropping
Origin
Eavesdropping could be considered Packet Sniffings younger, stronger, but less intelligent
brother. To provide context and follow up on this analogy, Packet Sniffing is more
intelligent in which it requires knowledge in order to know where to look and for what,
and in the end it returns information which in turn requires a good mind to know how
to use. Eavesdropping however merely plays out or outputs a conversation, making it
hypothetically no different from phone tapping.
To note, this section deals with Eavesdropping as a standalone issue, there are tools
available for eavesdropping on a certain connection, attempting to pick up any UDP
Packets and play them, regardless of IP Address. While the more classical way of viewing
eavesdropping is that it is a level above Packet Sniffing, this work has the notion of the
opposite. From packet sniffing one can eavesdrop and not the other way around.
Eavesdropping is much more of a difficult subject to discuss, it bears so much similarity
to Packet Sniffing, yet it remains a different topic. Hence for interest of eliminating
repetitiveness this chapter will remain shorter.
Impact
”It is said that if you know your enemies and know yourself, you will not be imperiled in
a hundred battles...” - Sun Tzu The Art of War
Another adage dating back to first written history which rings true to this day, knowl-
edge is power as Sun Tzu told of in The Art of War, an intruder peering into your own
calls freely needs not much proof to warrant its position on the impact list.
Even more so, today there are techniques to spot a certain word uttered during the
conversation, so for instance if used in espionage or in tyrannous countries could have
severe implications.
Solvability
One would assume the easiest way to solve this issue is as the above issue was solved,
until recently most of the community working in this industry thought so as well. In
order to encrypt a VoIP Call without losing time to encryption it is also compressed
with Variable Bit Rate (VBR) to shorten the sending time. However, recent studies have
shown that the language of the audio being compressed could be accurately achieved from
the encrypted stream. This, along with searching for a single phrase it has been proven
with over fifty percent accuracy to be successfully able to identify whether an encrypted
stream contained a certain phrase or not. Which calls in question the true strength of
these methods of encryption [20].
Another research suggests to randomly pad the outputs of the VBR encoder to dif-
ferent lengths in order to overcome this issue[14].

3.1.3 Distributed Denial of Service (DDoS)
Origin
To compare to an older long distance communication method and to provide an analogy
of sorts. If a post man on average under normal circumstances has to deliver 1000 letters
per day, and on a certain day he receives 100,000 letters to deliver. There is virtually
little this man can do to distribute 100x his normal workload. It also comes as no surprise
to the postman when he opens these letters and finds than 99,000 of them are empty and
from the same person. This type of attack did not occur due to the cost and effort needed
to launch such a massive attack, numbers aside.
However, in a hypothetical word, where there was only one very fast postman, but
paper was free, and stamps were unlimited, such an attack could still be feasible, and
this is precisely what happens in VoIP DDoS attacks.
DDoS attacks first originated from 1989, as people discovered they could render ma-
chines inoperable using the -f (flood) command in ping.c source code. And soon developed
into almost bankrupting a high profile New York based ISP! (ISP!) in 1996 [5].
A flash forward to 2013, and the largest recorded high profile DDoS attacks of 300
Gbps in the first half of the year.
Impact
The sole reason this is not placed higher than it is on the impact list, is that there is
simply more to be gained from allowing a call to go through and knowing what was said
than denying it altogether. Denying the call however remains the next best thing.
The severity of the DDoS attack is limited only by its scope.
Figure 3.4: Simple DDoS Attack by Sisle

Solvability
DDoS attacks are growing daily in size and frequency, and are now used as prime tools in
Cyber Warfare. Everything from Governments to Gaming Companies have been at one
point in time been the target of DDoS Attacks, of various magnitudes.
Recent researches [15] have shown that, while SIP Servers vary from robustness and
at which point they reach a contrived Breaking Point, all of the servers available for use
today can indeed be knocked down by a simple flooding of Invite requests.
The solution mentioned was the implementation of a SIP Intrusion Detection System
(IDS), to expand on this, simply allowing users a limited number of attempts to send
invite requests before shutting them out of the server for a time would solve the issue,
since in order to place an invite request one needs to be registered on the server in the
first place.
This is a very solid potential for future work, if not the solutions mentioned but the
subject matter itself, as said above DDoS attacks are only getting stronger, so it is only
natural for the next focus of research to concern surefire ways of defending against DDoS
attacks.
To shed further light on the severity of the issue, companies dedicated to ”Cloud
Based DDoS Mitigation” have recently opened up and have attained immediate success
[5].

3.1.4 Spam over IP Telephony (SPIT)
Origin
If for example Bob knows that Carl is expecting an important call from Alice on the 13th
of April, and Bob wants to stop Carl from answering this call, a valid way of doing this
is repetitively calling Carl and hence making it seem for Alice that Bob is busy. This is
what is known as SPAM. SPIT however is much easier and less costly to execute.
Also it is much like E-Mail SPAM, except with E-Mail a person can go through them
all and in a sense Randomly Access the mails they deem important. Unlike E-Mail SPAM,
SPIT is more direct, the phone is ringing and will not stop ringing until it is answered or
declined. At the same time any legitimate calls are not being allowed into the system.
Also, E-Mails are scanned at an E-Mail server before being distributed to the user,
and hence most SPAM can be detected before it even reaches the user, unlike SPIT which
directly arrives to the user. E-Mails are also much easier to analyze, they give room for
analysis with the information they carry, yet a SPIT call cannot be determine pre-hand
for it arrives as a regular call would.
SPIT faced a difficulty in its definition, but recently it is being agreed on the definition
of: ”bulk unsolicited set of session initiation attempts (e.g., INVITE requests) [10], at-
tempting to establish a voice, video, instant messaging, or other type of communications
session. Meaning that SPIT could very easily be identified as Telemarketing of VoIP.
Impact
A step below DDoS attacks, but a sizable one at that. While DDoS attacks render an
entire server unusable, SPIT attacks only target bulks of people. To perform a SPIT
attack, the VoIP network is scanned and information regarding the IPs of the users on
the network is gathered. Afterwards attempts to establish calls with as much of these
users as possible being, and in the instance one picks up a message is relayed.
Solvability
As with all SPAM based attacks, simple black lists could suffice to prevent SPIT calls,
but this is a reactive solution and not a proactive one. And simply placing addresses
accused with SPIT in a blacklist is impractical at best.
A method of dealing with SPAM, or rather unwanted automation over the Internet
in general is Completely Automated Public Turing test to tell Completely Automated
Public Turing test to tell Computers and HumansApart (CAPTCHA) but even this can
be worked around by performing a CAPTCHA Relay Attack, by relaying it to human
solvers.

Also an IDS does not seem as viable here as it would in a DDoS Attack, even though it
does seem as if the IDS can identify a SPIT IP by the rate of calls it places and abnormal
behavior it displays there is still a way around it. The attacker could simply adjust the
call rate randomly, making it more diﬃcult for a pattern to be realized.
As a research claims, Any attacker who is able to: Device Spoof, SIP Identity Spoof,
SIP Header Spoof, Reputation Push or Pull, CAPTCHA Relay Attack, SIP Identity
Hijack, Call Rate Adapt and Account Switch, will in the end be able to breech most
present countermeasures.
The results of this same research were indeed very alarming and concerning;
”As an attacker we acted only with simple methods on the Application layer, but could
nonetheless ﬁnd ways to bypass countermeasures, without even exploiting SIP protocol
weaknesses or deploy methods of lower layer protocols. This showed us, that in order to
mitigate threats like SPAM over Internet Telephony, developers and administrators need
to challenge their solutions.
More research in this issue is a must, an explosion in these types of attacks can very
well be in the works, such as was the case with DDoS attacks.

Figure 3.5: Excerpt Highlighting 8 SPIT Skills

3.1.5 NAT Traversal
Origin
VoIP, or rather, SIPs issues with Firewalls originate from three major points. Older
Firewalls predate SIP entirely, or did not anticipate the need to let SIP Messages pass
unhindered, making for blocked SIP Messages entirely.
Yet, even with new firewalls VoIP systems seemed to struggle to preform, as the newer
firewalls put more emphasis on security over all else, and when a firewall finds a mass
of RTP packets wanting to pass through, it will feel compelled to check each and every
one. Causing an unsettling delay in the call, and in lower end computers possibly jitter
as well.
The last origin of issues with reach-ability stems from the impending depletion of IPv4
addresses, and the short term solution of NAT, as was described in Section 2.3, along
with how SIP Messages are constructed[9].
Since the internal IP Address is different from the Public IP Address the SIP message
leaving the network will hold the wrong internal IP Address and not the Public IP and
Port.
Impact
A SIP Packet going to its destination with a wrong return address has only one impli-
cation. The response will be sent to the wrong return address, and probably lost along
the way. This is however an issue with the setup of the system and has a multitude of
solutions.
Solvability
Simply using a NAT Box to change the IP Payload of the SIP packets would be enough
to solve this issue. This would allow for a simple change of the IP to the correct Public
and Port variant.
Application Level NATing could be also considered by adding an Application aware
gateway to handle the VoIP Traffic. Known as, Application Layer Gateways (ALG).
However this solution is flawed at its core, for it the ALG would have to change the
packet and hence decrypt the packet, meaning that this solutions defeats the purpose of
encryption.
The solution proposed by IETF is one which involves yet another protocol, and re-
quires the presence of a Relay Server. Skype however use a protocol of their own and it
would be advisable to follow in these footsteps when building a VoIP System.

3.1.6 Operating System
Origin
A VoIP System is as good as its underlying OS. A sentence taught to anyone willing
to set foot in the ﬁeld, and a fundamentally correct one at that. Until this point the
contention has been over abusing VoIPs inherent weaknesses, looking at the weaknesses
of an Operating System such as Windows however brings up a new host of other security
issues entirely.
Impact
Windows is inherently a weak OS to base any system which requires any form of consid-
erable security upon. Monitoring tools for windows are in abundance, whether they be
keyloggers or sniﬃng utilities, basing a VoIP on an OS such as windows only makes it
that much easier for intruders to attack the system.
Solvability
Cisco, a leading developer in the industry have long since migrated their systems and
services to a Linux based OS, and the same is advised for any VoIP System willing to
maintain a semblance of security.

3.2 Quality
Assuming all issues of securing VoIP Systems are done with, and a perfectly secure VoIP
System is created. The first issue this hypothetical system is going to have is a concern
for the quality of the calls in this system. Security does not come without a price, in this
case quality is favored over security or reliability. For instance, the media packets sent
are traditionally done using UDP, and while TCP is known to be the more reliable way
of sending a packet it is speed that is sought by using UDP.
For instance, as described in Section 3.1.5, newer firewalls are a direct representative
of better security measures, but the way they secure the network might lead to horrible
delays.
To return to real world analogies an argument can be made to relate between packets
traveling in coaxial Ethernet cables, and people traveling around the roads. Bringing this
argument to its bare bones, transportation is in essence an layer on which communication
was built. In order to get a message across , there must first be a way to get this message
across. A look back at the OSI models layers would provide further insight.

Figure 3.6: OSI Analogy
The idea behind this particular analogy, is to relate between the traveling packet
through cables, and the traveling cargo through roads. To achieve security when the
cargo is precious, the transport vehicles used would be better armored and tougher built.
This however means that it will not move particularly fast. The same is true for sending
data you wish to encrypt or protect over the Internet. The encryption on the data more
often than not leads to it being bigger in size and hence slower to send.
Also, computers these days can be compared to cities of vast scope, or a metropolis.
A modern day computer, at peak usage, can be charged with sending and receiving a
tremendous amount of files. To return to the analogy, a metropolis has crowded streets
because of the same reason. The bandwidth available to any certain user can be compared
to the roads available in and out of a certain metropolis.
So as not to delve even deeper into the OSI Layer analogy, it will suffice to mention
what has already been said above. And hence the coming subsections will tackle each of
the specific issues as has been handled in the Security section.

3.2.1 Bandwidth
Origin
This particular issue stems from the amount of other activities using up the bandwidth
available, along with the large bandwidth required to properly set up a VoIP call.
For instance, a soft-phone using any of SIP, H.323 or MGCP along with RTP sends
a single voice packet every 10 to 40 ms. This can be either compressed, uncompressed or
encrypted. RTP will send the same number of packets regardless. It can take anywhere
from ten to a hundred packets to carry a single word using this standard system in the
best of cases, so the need for bigger bandwidth becomes more apparent.
Fundamentally the delay from end to end needs to remain as low and little as possible
for the quality to remain at an adequate level. As the size of the packet decreases the time
it takes to create and send it go down proportionally to it. Yet the need for bandwidth
relates with inverse proportionality to the size of the packet. The smaller the packet, the
more packets are sent, and the bigger the packet overhead becomes.
The issue with long packets however is that they are being sent over UDP, meaning
that if a packet is lost it will not be easily fixed.
On average, a packet will be sent each 20-30ms, depending on the implementation in
question, meaning that in a single second a total of about 50 packets are sent, and as
mentioned in section 2.2.1, the digitized voice field can carry up to 320 bytes of voice.
Meaning that for 50 packets per second a total of 16 KB are being sent in the digitized
voice field alone.
Impact
” In reality, there is no Voice over IP. It is really voice over RTP, over UDP, over IP
and usually over Ethernet. The headers and trailers are required fields for the networks
to carry the packets. The header and trailer overhead can be called the shipping and
handling cost.
Keeping this in mind, a few calculations and numbers should be considered. The RTP,
UDP, IP headers add 40 bytes to the digitized voice mentioned, the Ethernet trailer and
header contribute with 18 bytes overhead. A total of 58 bytes of overhead are generated
outside of any voice bytes in the packet, this can account for 80 to 20 percent of the
bandwidth used in a VoIP call. This is in a single packet, and this shows how inefficient
shorter packets are in contrast to longer ones. And this is all before any encryption is
added. [1]
From the above discussion we can conclude that the bandwidth consumption of a VoIP
call relies on, Compression Techniques used, Packet Overheads, and Network Protocol
used.

Solvability
An issue such as this has indeed attained a significant amount of attention and for the
most part can be considered solvable, with various applicable solutions.
The first of which would be compressing voice in the RTP packets, which in the end
makes up the majority of the bandwidth usage. Which is how Codecs came by, and will
be discussed in depth in the coming section.
However compressing voice comes at a price and creates an interesting trade off which
needs to be taken into consideration. The lower the size of the file the easier it is to
send and the smaller the delay, however compression in essence usually involves a loss of
data. Hence in order to better the quality of a call for a low bandwidth link, it could
be that the quality is being brought down in terms of the actual call itself. Also, while
compression decreases the delay in sending the packet it does create a sort of processing
delay to compress the packet in the first place.
Strategies on choosing a certain codec will be discussed in the coming section, this
section could be considered as an introductory section to the coming one, or the coming
a supplementary section to this[1].
Figure 3.7: Bandwidth Calculation
Another way to manage this issue, is to allocate bandwidth where possible to VoIP
calls alone. This can be attained by calculating the bandwidth needed by the system and
reserving this amount exclusively for the VoIP calls.

3.2.2 Codecs
Not all the roads in the world are the same, some are paved well and can allow for any
type of vehicle to pass over them. Some are rougher and require tougher more durable
vehicles to navigate, and some are dirt roads that require lighter vehicles to traverse.
It then falls to reason that the different the road, the different the experience of
navigating it. The same is true to Internet connections. A dial-up connection cannot
be expected to offer the same level of quality that an Asymmetric digital subscriber
line (ADSL) or Cable connection offers. This will be further discussed in a later section,
but for now the issue at hand is accommodating for these variable bandwidths.
Origin
Since the first telephone calls were being made, the American Public Switched Tele-
phoneNetwork (PSTN) had built a network underground of a copper cable pair per ac-
tive call. This solution however was deemed not good enough when the areas they were
using became saturated with cables. In the 1950s however a technique was created by
the American ATnT communications company which allowed for a single copper wire to
hold more than a single call, by digitizing the previously analog speech they managed to
achieve 24 calls per pair of copper wire, this was the earliest form of compressing speech.
Voice compression carried on to influence even digital cell calls which were at the time
operating at 8 64 Kbps, and while it is not regularly applied to LAN connections, this
showcases how compression can be useful at any range, hence CODECs were created to
choose based on the bandwidth available, the appropriate compression.
Impact
The word CODEC, comes from the essential parts on compressing a speech signal, which
are: COding, and DECoding. The impact of CODECs has been discussed extensively in
the previous section and in order to avoid repetition will only be briefly mentioned here.
The issue at hand however is not what a CODEC is, it is concerned with choosing
the proper CODEC for a certain VoIP System. As mentioned this depends primarily on
the bandwidth in hand, and how it influences the system is illustrated in figure 3.8.

Figure 3.8: Codec Influence
Solvability
As is mentioned in the Bandwidth section, given the bandwidth available along with the
available codecs, a good VoIP System can dynamically change the codec to use for each
call.
For instance, if the network is congested at peak time, a lower quality codec should
be used to compensate for the lack of available bandwidth, and on the other hand, during
low periods a higher quality codec could be used.
The following are the four most popular codecs [1] along with an analysis of each,
the last table will showcase the codecs Cisco use along with a table provided from their
website and official docs.
G.711, the industry standard which digitizes voice, with no encryption at 64 Kbps.
G.722, as with G.711 it operates at the same 64 Kbps, but offers much higher quality
speech by delivering analog sound range of 7kHz as opposed to the 3.4kHz by its
G.711 counterpart.
G.723.1, reduces bandwidth consumption greatly but the speech is noticeably poorer than
its counterparts. It runs at 6.3 5.3 Kbps.
G.729, compresses at 8 Kbps, with a quality that falls just short of G.711.
Quick suggestions would refer G.722 for the best links, G.729 for the moderate ones,
and G.723.1 for the worst of links.

A more detailed look can be had at the other available codecs from ﬁgure 3.9 taken
from Cisco [3].
Figure 3.9: Codecs

3.2.3 Queueing
Traffic lights exist in the digital world as much as they do in the real world, a big part of
QoS is prioritizing which traffic moves on and which is delayed based on its classification
or characteristics.
Origin
When dealing with traffic in the real world, very little distinguishment is made, leading
to important cargo being put behind lesser important ones when being processed due to
the nature of how things work.
However in the digital world, there is a way to classify packets based on their priority,
based on how fast they need to be dealt with. The issue at hand is congestion, with the
various forms of traffic on any given system at any given time, any VoIP System will be
faced with the issue of Congestion.
Impact
Simply put, if handled in an improper fashion, congestion will lead to huge amounts of
lag inside calls, without proper prioritizing for the packets carrying the voice a proper
call would never take place.
Solvability
To solve the issue of congestion and to ensure that the higher priority packets be dealt with
immediately, a series of Queueing Systems were established. This section will highlight
four queuing systems, and their role in VoIP Systems [12].
First In First Out (FIFO), is the first, easiest, and most inefficient method. In reality
it is not a real queueing system, it simply transmits by order of arrival.
Priority Queuing (PQ), this method assigns four different priorities for each packet
based on its classification, ranging from High, Medium, Normal, and to Low. Simply
put, when packets are received those in the High Queue are transmitted before those in
medium, and then those in normal and finally those in low. The fundamental flaw in this
system is that the Low Priority Queue might never be handled if there is an influx of the
higher priorities.
Custom Queueing (CQ), sixteen queues are offered with this method and as with PQ
the packets are assigned to these queues based on classification. It operates in a round
robin and its goal was to stop protocol starvation, this method does however introduce a
large amount of overhead and can prove to be detrimental.
Weighted Fair Queueing (WFQ), dynamically assigns bandwidth to the traffic reliant
on the weight or IP Precedence Value within the IP headers. This method however may

stop high priority packets from being sent since it dynamically assigns bandwidth, and
hence could make for an undesirable latency.
Out of these queuing methods none ﬁt the needs of a VoIP System, and hence mixing
and merging between these methods to create a Hybrid ﬁt for a VoIP System is the best
approach to handle congestion.

3.2.4 Low Speed Links
Catering for lower speed links can be difficult, but what exactly is defined as a low speed
link? The speeds considered by modern day researches to be slow links range from 56
kbps, to 2 Mbps. And hence special care should be given to those links.
Origin
Bandwidth in developing countries, or indeed any bandwidth that passes through un-
derwater cables, is very expensive to attain. Taking into consideration the weak infras-
tructure, poverty rates, and general quality of life in these countries would lead to the
conclusion that a well set up person would most likely actively work under a low speed
link.
Impact
What this means however, is that there is little and less bandwidth to provide for whatever
work is being done alongside a VoIP Call, which takes high priority in its share for
bandwidth.
This means that not all the VoIP Quality Assurance Parameters are satisfied, delays
could increase the 150ms barrier, jitter extends the 25ms margin, and packet loss exceeds
the maximum allowed.
Solvability
Researches have shown that the methods mentioned in this paper can be enough to deal
with these types of links. [13]
More advanced Queuing Algorithms such as Weighted Random Early Detect (WRED)
and Low Latency Queing (LLQ), have been proposed as possible solutions.
Mixed with various selection of codecs, and through testing of these various Queuing
methods these results were attained.
For the speeds between 2Mbps and 128kbs, WFQ showed prominence, along with
G.711, while the G.728 has shown good performance for all speeds but will be excluded
on account of its much lower quality. For the lower links however no form of satisfiable
QoS was obtained after applying the various queuing algorithms and the lowest OS codecs.
Researches however still favor the G.723.1 codec as a highly recommended to use codec
for future use. The research also showed that the main culprit of QoS Degradation in
low speed links was jitter.

3.3 Dependency
One of the prominent challenges that face VoIP Systems outside of the actual imple-
mentation of the actual systems, were the basic limitations which VoIP Systems need to
function.
In this section, a discussion on VoIP Systems reliance on power will be held, alongside
a comparison between VoIP Systems reliance on the Internet, and telephones to the cable.
Various solutions will be discussed for one of the two issues, and general discussion will
be held over the other.
3.3.1 Power Dependency
Computers are not designed to run without power, they are in essence, machines which
handle electric signals in the basic binary form. And so it did not occur to the leading
developers of VoIP Phones that they would need to establish a method to avoid using
power cables for their Phone sets.
Origin
The very ﬁrst phones were not developed with smart power consumption or power source
choosing in mind, and hence as will all computer related appliances they came with a
cable. Many modern VoIP Phones still do.
Figure 3.10: Cisco VoIP Phone
Figure 3.10 highlights how to this day, expensive and capable VoIP Sets still use Power
Adapters.
Impact
As with anything that involves power cables, a simple cut in electricity will render the
entire VoIP Communications System of any institution useless.
But is this a real problem? This paper believes this is a real threat to communications,
and a simple contrast to telephones will show that they cannot be made inoperable from
a simple electricity cut. It is just not acceptable by modern standards.

Solvability
Figure 3.11: PoE
An elegant solution to this issue was inspired from where phones get their power sources.
The solution meant for an adapter to be placed before the VoIP Phone can connect to
the Switch, and from the switch the adapter will send both power and connectivity to
the VoIP Phone.
This makes it much easier to maintain communications by keeping the Switches on a
backup power source instead of all the VoIP Phones maintained by the company.

3.3.2 Internet Dependacy
There is not much that should be discussed in this matter, but it is important to bring
up none the less.
As with regular phones which are dependant on their connection to the PSTN, VoIP
Phones are dependant on their connection to whatever outlet they should be connected
to. Whether it be a WAN connection, or a Local one, should the connection be severed
the VoIP System will be rendered inoperable.

3.4 Emergency
The last of the glaring challenges this work focused on, but by all means not the last
challenge facing VoIP in general.
”The ability to access emergency services by dialing 911 is a vital component of public
safety and emergency preparedness. It is imperative that consumers of telephone service
be able to reach emergency services regardless of the technology used to place a 911 call.”
[7]
This is a statement issued on the Federal Communications Commission (FCC)s own
website, which is responsible for moderating the standards of communications in the
United States of America.
Origin
As with the power dependency issue, VoIP Systems were initially created as a way to
have vocal exchanges over the Internet or over LAN. It was not initially developed with
the mindset of defeating PSTN Telephones.
People simply aspire to use the most cost efficient methods possible to them, and
hence VoIP Systems were brought into contention with PSTN Telephones.
The way 911 calls operate is solely through the PSTN, and so it would seem that
all LAN VoIP Systems would not have the remote ability to contact 911, or even VoIP
Systems in general.
Other than this, traditional phones have a specific phone number linked to a specific
fixed address, and so upon reaching 911 Emergency Call, the location is quickly identified
and aid can be quickly offered.
However in VoIP Systems a single user can connect from virtually anywhere if the
service allows it, whether it be from home or in office. This portability raises many
challenges for VoIP Systems in regard to emergency calls.
Impact
Needless to discuss, the impact of not being able to contact 911 is great by will vary. For
instance in the office where there probably is a normal telephone in the vicinity it will
not be as big an issue as in a corporate building which focuses its communications soley
on VoIP.
Aside from the impact in reality, this issue is a defying block between VoIP Systems
chance at eclipsing PSTN phones. And so in order for VoIP Systems to progress and
develop in the mainstream consumer market a solution will need to be put into action.

Solvability
People who saw potential in the current VoIP Market did not sit idly by as this hinderance
aﬀected VoIPs development. Other people saw opportunity in this situation and created
VoIP Emergency Services.
Figure 3.12: VoIP Emergency Service
The way this operated as illustrated by Northern911s advertisement in Figure 3.12,
was the 911 call would be made from anywhere in the VoIP System, it would then be re
routed via the phone system to Northern911s Servers where they would handle the call
and use the standard PSTN Technology to reach the distressed users local 911 service
and hence solving the issue, although this does entirely depend on the availability of
Northern911s Servers and Employees.
The more practical approach as was required by the FCC, was to Interconnect VoIP
Systems to the PSTN. This was required of all VoIP Providers who want to sell their
services to as many people as possible, and hence allowing the VoIP User to connect
through VoIP to the E911, which is an enhanced emergency call service.

Chapter 4
SPIT Simulation
In order to not restrain this work to theoretics, and to further elaborate on the issues
raised by this work. Collaboration with Ahmed Khaled Saad Metwally took place, in
which this work and his merged for mutual benefit.[11]
A Running VoIP System was needed in order to present the chosen topic, which
in order to present at peak capacity needed to be restrained to a single topic, as was
suggested.
For the topic, SPIT Attacks were chosen, since it is a good basis for future work, and
can be underestimated by the majority of people. A demonstration in the true power of
SPIT even on a local scale should reveal the fact that it is a real threat that will rear its
face with the spread of VoIP Systems.
To find a suitable VoIP System, which had an open source code that was under-
standable and easy to manipulate would prove to be difficult, after much research the
conclusion to collaborate and use Ahmed Khaled’s VoIP System using Java would be the
safest and best option available. After having already build the client, the collaboration
took place when connecting it to a server, particularly the setup of a server.
While this may be slightly irrelevant to the SPIT Attack, the process should still be
mentioned and documented.
4.1 Server
Finding a suitable VoIP Proxy Server which did not act as a Private Branch Exchange
(PBX) took time to locate and install. Bearing in mind that the only Linux distributions
available at the time was Ubuntu, which was run over Oracle’s Virtual Machine. Hence
the only choice with which there was sufficient experience was Windows.
41

CHAPTER 4. SPIT SIMULATION 42
4.1.1 Failed Attempts
At first, servers such as Asterisk and 3CX were tried out, but after many compatibility
issues with Windows 8 for 3CX, and after Asterisk began showing promising signs, these
two servers turned out to be PBXes and not Proxy Servers as was required.
Kamailio and reSIProcate were the two next server to be tested, but they simply did
not run under the available Linux distribution, after attempting install Kamailio from the
Ubuntu Application Manager, as well as manual installation to compilation from source
code, Kamailio and reSIProcate proved to be too difficult to set up, which contradicts
their advertisement of being easy and fast to set up.
Going back to Windows based servers, OfficeSIP was first tested but the response
codes seemed to be off and so was abandoned prematurely. A variety of SIP Servers
came after, partySIP, MSS, simpleSIP. All of which behaved and reacted in ways that
directly opposed the RFC. And hence our work saw a return to OfficeSIP as a last gasp
effort before writing a customized server.

4.1.2 OfficeSIP
Figure 4.1: OfficeSIP GUI
Finally the OfficeSIP Server functioned as intended, it served as a Registrar and Proxy,
it saved up to a hundred users, and operated with accordance to the RFC. After creation
of user accounts on the server, and testing their connectivity to the client, results proved
to be satisfactory and the server was finally selected.

4.2 Client
Ahmed Khaled’s Client, is a Java based SIP Client as this was the objective of his own
thesis. To help out, the GUI was created in collaboration. The following figures will
showcase the GUI created for the client along with its capabilities.
Figure 4.2: Client Login Screen
In order to connect to the OfficeSIP server, a username needs to be created first on
the OfficeSIP server. Hence, the client login screen takes the Server IP Address along
with a username and a password. It then sends a registration request to the server with
this data (after the authentication process), and connects to the server if a user with the
given name and password is given.

A Couple of scenarios could lead to a return to the login screen and failure to connect.
A wrong username or password will return a notiﬁcation to the user of the issue, if the
server itself is not available the application will time out and notify the user of the issue
as well.
Figure 4.3: Client Login Screen - Connecting

This then moves the user into a call room, which contains a text box in which the
user desired to be called is typed and a room is open with both users.
Figure 4.4: Call Room
The application uses GUI manipulation of buttons to manage the rooms, to stop users
from making multiple calls at the same time, or attempt to end a call they are not in.
(a) Chat Room In Call (b) Chat Room Out of Call
Figure 4.5: Chat Room States

4.3 Modiﬁcations
4.3.1 GUI
In the interest of not needing to include a multitude of Figures to showcase the modded
client, only the important parts or diﬀerences between the Vanilla client and the modded
one will be discussed.
The aim of this modded client, is simply to be used when presenting the work, and
to show that SPIT is a real issue where VoIP Systems are concerned.
Figure 4.6a shows the main menu of the modded client, the option to launch the
unmodded client is still available for testing purposes, then there is the option to start
the SPIT Attack process, or return to the illustrations for presentation purposes, or to
review not change a few settings.
Figure 4.6b shows the settings available to be reviewed, the server and current IP
Addresses are handled in this screen.
(a) Modded Client Main Menu (b) Modded Client Settings
Figure 4.6: Modded Client Settings

The call room has been modded to better reflect the nature of the activity, it still
takes a target user and begins a session in which a SIP Attack can be initiated.
Figure 4.7: Modded Call Room
The control room is for testing and surveillance purposes, it is to remind who is under
attack and what is the current status. Whether the user is listening to Advert1, or
Advert2, or the user is attempting to close the call, or if the user is busy etc.
Figure 4.8: SPIT Attack Control Room
This is a simple SPIT Simulation but it serves the purpose, future work on this
simulation could be to include which files to be sent, which part of the file is being
listened to and overall better control on the SPIT Attack.
Figure 4.9: Logout
This simulation simply selects at random from a list of five
possible adverstimsents and plays them, once the user end the
call it autonomously redials the user and plays another advert at
random.
The fact that the user will never exit the busy state is what
makes SPIT dangerous, this means that this user is now virtually
out of the system.

4.3.2 Code
This section details what was changed in Ahmed Khaled’s Client in technical terms. To
be noted as a reminder that the client was made entirely in Java and hence the code
displayed in this chapter is Java code.
For a detailed description on how Ahmed Khaled handled his own client, the report
VOIP in Java is available and is cited here [11].
The coming section will dissect the changes and tackle them per class.
messageprocessor
Listing 4.1: Modified RTP Sender
public void statusIncall(String Victim);
// Tells the attacker that the call has been established
public void statusCalling(String Victim);
// Tells the attacker that the user is being called
public void statusUserEndedcall(String Victim);
// Tells the attacker that the user ended the call
public void statusUserOffline(String Victim);
// Tells the attacker that the user is offline
public void statususerbusy(String Victim);
// Tells the attacker that the user is busy
These methods were added to the messageprocessor interface, to facilitate communi-
cation between the back and front ends.
They handle the status box shown in figure 4.8 on page 48. The statuses available are
the ones the attacker needs to concern himself with, such as whether the victim’s phone
is ringing, or whether the call is established and a certain advert is beind played, or if
the user ended the call and the SPIT attack attempts to redial, or if the user is simply
offline or is in a call.

client
Listing 4.2: Modiﬁed Client
public void processBye(Request request,
ServerTransaction serverTransactionId) {
try {
messageprocessor.processEnableCall();
messageprocessor.statusUserEndedcall(victim);
// Alerts the attacker that the user has closed
if (serverTransactionId == null) {
return;
}
Dialog dialog = serverTransactionId.getDialog();
Response response = messageFactory.createResponse(200,
request);
serverTransactionId.sendResponse(response);
rtpreceiver.Player.stop();
rtpreceiver.Player.close();
rtpsender.kill();
this.invite(ServerIP+":5060",victim);
// Calls the victim again autonomously
} catch (Exception ex) {
ex.printStackTrace();
System.exit(0);
}
}
The above code snippit is a key change, the one that keeps calling the victim over
and over, which simply ﬁnds out if the user ended the call and calls them again.
if (response.getStatusCode() == Response.RINGING) {
messageprocessor.statusCalling(victim);
//Alerts the attacker that the victim’s phone is
ringing
playSound("phonecalling.wav");
}

Above code highlights the way the attacker is notified of a different status, in this
example ringing, it is the same throughout the remainder of the client and will be put in
appendix B.
if (response.getStatusCode() == 487) {
clip.stop();
//Stops the SPIT Attack
}
Finally the last important bit in the client is where the SPIT Attack is finally stopped.
MainMenu
Listing 4.5: Modified MainMeniu - Attack
//Victim under attack
public void statusIncall(String Victim) {
for(int i=0;i<rooms.size();i++){
if(rooms.get(i).ipAddress.equals(Victim)){
rooms.get(i).textArea.setText("IN CALL - CURRENTLY
PLAYING ADVERT");
break;
}
}
}
As per accordance to the messageprocessor interface shown above these methods were
created in the MainMenu class to inform the attacker of the status of the Attack.

Chapter 5
Conclusion and Future Work
To summarize, this work has focused on bringing together the most glaring issues and
challenges that face VoIP Systems. In an attempt at becoming something of a reference
point upon which future works could be based upon, and hence a total of 13 topics were
discussed, most of which require yet more investigation.
When considering the title of this work, one should also consider the question of
whether or not each topic has been solved yet, and if not then what are the proposed
solutions.
In this chapter the summaries of all the proposed solutions will be gathered for ease
of traversing.
52

CHAPTER 5. CONCLUSION AND FUTURE WORK 53
5.1 Security
5.1.1 Packet Sniffers
The suggested solution to this issue, was to find a good trade-off between security and
compatibility depending on the system in question, a casual chat application will need
to be more compatible on more devices than a Secret Service Agency would need, and
in turn the Agency would prefer to capitalize on the strongest security possible hence
decreasing the amount of devices with the capability of compatibility drastically.
For future work in this matter, the suggestion would be to research for the possible
optimal level of security to compatibility, for instance creation of a rating system to rate
the security and the compatibility of the VoIP System in terms of encryption and a study
to ensue to establish a Security to Compatibility ratio.
5.1.2 Eavesdropping
Assuming an encrypted system, to further protect against eavesdropping researches sug-
gest to use a random length padding to the VBR encoded output to confuse and throw
off the newer methods of realizing a phrase when uttered throughout a call.
This subject, while very specific, is considered fertile ground for future work. The
two strongly backed researches mentioned should be read and considered, and to build
on their work the suggested solution implemented. The reports in question are [20] and
[14].
5.1.3 DDoS
Further research in this area is a must, the need is rising quickly and the only real defence
available it to mitigate the DDoS attack, high profile targets should look at Cloud Based
Mitigation companies, while more middle ranged targets should look to implement an
IDS.
The toughest task to tackle due to the ease of its execution but the one in most need
of handling.
5.1.4 SPIT
An area of great controversy as there is a vast multitude of solutions available, but all
possess exploitable weaknesses, anyone with the ability to: Device Spoof, SIP Identity
Spoof, SIP Header Spoof, Reputation Push or Pull, CAPTCHA Relay Attack, SIP Iden-
tity Hijack, Call Rate Adapt and Account Switch, will breech all currently available

countermeasures to SPIT, although a combination of all the suggested methods might
just prove too formidable to breech at once.
As VoIP Systems spread this issue will grow with it, future work here would be well
based on Rachid’s work, and would lead to a direct solution or the conﬁrmation of the
need of a new method of thought to solve this issue.
5.1.5 NAT Traversal
One of VoIPs greater challenges, and the best way to solve would be to either use IETFs
STUN and TURN protocol and server, or follow the path Skype took and write your own
custom protocol along with a relay server.
It could prove to be good practice to develop an open Java Based API to handle these
STUN and TURN protocol and sever creation.
5.1.6 OS
Switching to a Linux based OS seems to be the only feasible solution to this issue, if more
security is what is desired. Moving at least the servers to a Linux based system would
be advisable if the VoIP System wishes to sell on Windows. The servers at the very least
need to be well protected against attacks.
A rarity, but no future work is suggested in this area, unless a massive undertaking
of a windows based OS being produced with satisfactory design elements.

5.2 Quality
5.2.1 Bandwidth
The multiple methods that could be employed to solve this issue involve two main stand-
out solutions. Depending on the situation, the available bandwidth could be allocated
to always save enough bandwidth for VoIP Communications to go through unhindered,
which is a way that works in a controlled environment as in an Office or a place of work.
The other prominent solution would be to use higher compressed Codecs, depending
on the available bandwidth, for this a calculation of the bandwidth available and the
bandwidth needed for a codec to function without causing issues would be needed and is
described in Figure 3.7.
5.2.2 Codecs
Figure 3.9 features the most prominent codecs as mentioned by Cisco along with the
required Bandwidth to run each codec. Bearing in mind that not most PCs have all the
codecs installed by default. The way this issue is solved classically would be through
a negotiation of codecs before the call starts hence choosing a codec that will function
correctly on both bandwidths of the caller and the calee.
As for the most famously used of upcoming codecs, a discussion has been held in
Section 3.2.2 concerning each one.
Suggestions for future work in this area involve a way to negotiate and install codecs
based purely on the bandwidth at runtime. Or a simple deep research into the available
codecs, backed by a thesis on which one should be the industry standard.
5.2.3 Queueing
As was discussed in section 3.2.3, this issue has multiple answers, but not a simple
solution. Meaning that there are a few popular queuing algorithms such as FIFO, PQ,
CQ, WFQ, but none of these are one hundred per cent suitable for VoIP Traffic handling,
a much more complex merge between these queueing algorithms would be a start.
Hence it is sold ground for future work, a work under the title of Queueing for VoIP
Traffic could unfold new and better ways to direct VoIP Traffic, but will require a good
amount of knowledge in the subject matter. And while the different queueing algorithms
could indeed be simulated, testing in real time would require access to a programable
router.

5.2.4 Low Speed Links
The current solutions for Low Speed Links are not satisfactory, yet research in the matter
is not considered to be a priority since the world is advancing in terms of speed and
quality of links available, yet research in this field is still crucial. Developing countries,
or countries with weak infrastructure for the Internet such as Egypt for example could
benefit from a detailed study and research in this particular field.
A look in [13] would prove useful for future research.

5.3 Dependency
5.3.1 Power
Current solutions to this issue as is shown in Figure 3.11, involve the use of a PoE adapter,
which is a good, practical and applicable solution, but could raise the cost and connections
needed in the VoIP network significantly, if for instance a wire could be developed that
carried PoE without the need for this adapter entirely, then this would eliminate a few
of these issues.
Future work in this certain field is not encouraged as it is purely hardware focused and
already in development, however if this were to be pursued then a more abstract topic
could open up, the possibility of sending power over wireless has been long discussed and it
would be applicable in this case for the benefit of eliminating multiple wired connections,
but would bring about a world of security issues.
5.3.2 Net
As was mentioned in Section 3.2.3, the absence of a network will render VoIP Communi-
cations useless.
However a system could be developed which employs the idea of an answer machine,
but the opposite way around. If the connection is severed on the callers end, the system
detects the downed connection and switches to a buffer mode. In which calls from the
caller will be recorded and sent once the network returns.

5.4 Emergency
The two solutions mentioned in section 3.4 are the two most prominent and obvious
solutions. Either connect to a private agency which handles the call for the VoIP System
depending on the location. Or interconnect the VoIP System with the PSTN so that the
emergency call can go through to the E911 service.
Future work in this topic is however viable, since little work has been done in the topic,
suggestions would be to research ”How to Integrate VoIP Systems with the PSTN”

5.5 Last Words
To reiterate what was said in Sections 1.1 and 1.2, this work does not claim to solve a
single issue, or discuss it in depth. This works aims to be a staple for future works to
come, the topic of VoIP Systems is an uprising topic, and one which could soon change
much of how we communicate.
Much development has gone into this topic, yet the articles about the challenges facing
it are not nearly as well rounded as need be. What this work claims to be, is a reference
point from which future works could spawn in an organized fashion.
This work should be thought of as a sort of check list, or progress report on the status
of VoIP Systems, how far we’ve come, the problems that have spawned since the early
days of VoIP Systems, how they originated, how sever they could be, and ﬁnally how
they could be solved.

Appendix A
Lists
VoIP Voice over IP
DDoS Distributed Denial of Service
SPIT Spam over IP Telephony
QoS Quality of Service
SIP Session Initiation Protocol
IETF Internet Engineering Task Force
SMS SIP Messaging Service
IM Instant Messaging
RTP Real Time Protocol
UDP User Diagram Protocol
LAN Local Area Network
MAC Media Access Control
NAT Network Address Translators
HTTP Hypertext Transfer Protocol
FTP File Transfer Protocol
ADSL Asymmetric digital subscriber line
MMS Multimedia Messaging Service
TCP Transmission Control Protocol
61

APPENDIX A. LISTS 62
HDD Hard Disk Drive
DVD Digital Video Disc
VCD Video CD
SVCD Super VCD
DVB Digital Video Broadcasting
MPEG Motion Pictures Experts Group
AVI Audio Video Interleave
ASF Advanced Systems Format
WMV Windows Media Video
WMA Windows Media Audio
MP4 MPEG 4
MOV QuickTime File Format
3GP Third Generation Partnership Project
OGG Ogging
OGM OGG Movie
MKV Matroska Video
WAV Waveform Audio File Format
FLAC Free Lossless Audio Codec
FLV Flash Video
MXF Material eXchange Format
MIDI Musical Instrument Digital Interface
SMF Standard MIDI File
SIPS Secure SIP
TLS Transport Layer Security
SSL Secure Sockets Layer
VBR Variable Bit Rate

APPENDIX A. LISTS 63
IDS Intrusion Detection System
CAPTCHA Completely Automated Public Turing test to tell Computers and
HumansApart
ALG Application Layer Gateways
PSTN Public Switched TelephoneNetwork
FIFO First In First Out
PQ Priority Queuing
CQ Custom Queueing
WFQ Weighted Fair Queueing
WRED Weighted Random Early Detect
LLQ Low Latency Queing
PoE Power over Ethernet
FCC Federal Communications Commission
PBX Private Branch Exchange

List of Figures
2.1 Technologies and Issues (Security) . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Sip Invite Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 RTP Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 SCCP UDP Packet Capture . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 NAT Operaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Input Media and Formats of VLC . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Organization of Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 SIP Invite Request, as captured by Wireshark . . . . . . . . . . . . . . . 16
3.3 A Much more complicated SIPS message . . . . . . . . . . . . . . . . . . 17
3.4 Simple DDoS Attack by Sisle . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Excerpt Highlighting 8 SPIT Skills . . . . . . . . . . . . . . . . . . . . . 23
3.6 OSI Analogy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Bandwidth Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 Codec Inﬂuence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.9 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.10 Cisco VoIP Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.11 PoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.12 VoIP Emergency Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1 OﬃceSIP GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Client Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Client Login Screen - Connecting . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Call Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
64

LIST OF FIGURES 65
4.5 Chat Room States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6 Modded Client Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.7 Modded Call Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.8 SPIT Attack Control Room . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.9 Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
C.1 Packet Sniﬃng Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C.2 DDoS Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
C.3 Eavesdropping Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 72
C.4 New Firewalls Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.5 Old Firewalls Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
C.6 OS Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.7 Bandwidth Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.8 Good Bandwidth Illustration . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.9 Medium Bandwidth Illustration . . . . . . . . . . . . . . . . . . . . . . . 75
C.10 Bad Bandwidth Illustration . . . . . . . . . . . . . . . . . . . . . . . . . 76

List of Tables
2.1 Provisional SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Successful SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Redirect SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Failure SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Server Failure SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Global Failure SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
66

Appendix B
Code
Here are the snippits of code that have not been referenced specifically inside the docu-
ment. For specific code segments check section 4.3.2.
Listing B.1: Modified RTP Sender
if(Main.norm){
MicInfo = new CaptureDeviceInfo("DirectSoundCapture",
new MediaLocator("javasound://"),null);
DeviceMediaLocator = MicInfo.getLocator();
source = Manager.createDataSource(DeviceMediaLocator);
}
if(Main.SPIT){
MediaLocator camDeviceMediaLocator =
new MediaLocator(advertlist.getItem(rand));// rand is randomly
generated.
source = Manager.createDataSource(camDeviceMediaLocator);
}
67

APPENDIX B. CODE 68
Below is listed the modifications made to the Client class. (Which are not refrenced
in section 4.3.2)
Listing B.2: Modified Client
if (response.getStatusCode() == 486) {
messageprocessor.statususerbusy(victim);
//Alerts the attacker that the victim is busy
clip.stop();
playSound("phonebusy.wav");
clip.stop();
x.dispose();
messageprocessor.processEnableCall();
CallTrytimer.restart();
CallTrytimer.stop();
}
Listing B.3: Modified Client
if (cseq.getMethod().equals(Request.INVITE)) {
messageprocessor.statusIncall(victim);
//Alerts attacker if the call is
established
if(clip.isOpen()){
clip.stop();
}

APPENDIX B. CODE 69
Below is listed the modifications made to the MainMenu class. (Which are not re-
frenced in section 4.3.2)
Listing B.4: Modified MainMenu - Calling
//Victim being called
public void statusCalling(String Victim) {
rooms.get(i).textArea.setText("NOT IN CALL -
CALLING USER");
break;
}
}
}
Listing B.5: Modified MainMenu - Call Ended
//Victim ended call
public void statusUserEndedcall(String Victim) {
USER ENDED >>> REDIALING");
break;
}
}
}
Listing B.6: Modified MainMenu - Offline
//Victim offline
public void statusUserOffline(String Victim) {
USER OFFLINE");
break;
}
}
}
Listing B.7: Modified MainMenu - Busy

APPENDIX B. CODE 70
//Victim busy
public void statususerbusy(String Victim) {
USER BUSY");
break;
}
}
}

Appendix C
Illustrations
This appendix holds most of the Illustrations to be used when presenting this work, to
be noted that it is mostly interactive yet having them in the paper could prove to be
beneﬁcial.
Figure C.1: Packet Sniﬃng Illustration
71

APPENDIX C. ILLUSTRATIONS 72
Figure C.2: DDoS Illustration
Figure C.3: Eavesdropping Illustration

Figure C.4: New Firewalls Illustration
Figure C.5: Old Firewalls Illustration

Figure C.6: OS Illustration
Figure C.7: Bandwidth Illustration

Figure C.8: Good Bandwidth Illustration
Figure C.9: Medium Bandwidth Illustration

Figure C.10: Bad Bandwidth Illustration

Bibliography
[1] Gary Audin. Voip bandwidth fundamentals. 2008.
[2] Ed B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, and D. Gurle. Sip
message extension. Standards Track, 2002.
[3] Cisco. Voice over ip - per call bandwidth consumption. 2006.
[4] Gerald Combs. About wireshark. 2014.
[5] defense.net. Ddos attack timeline: The history and changing nature of ddos attacks.
2014.
[6] K Egevang and P Francis. The ip network address translator (nat). Request for
Comments, 1994.
[7] FederalCommunicationsCommission. Voip and 911 service. 2005.
[8] Nick Galea. The main sip invite header ﬁelds explained. 3CX Blog, 2010.
[9] HughesCoporation. Voip and it’s challenges. 2006.
[10] Rachid Khayari. Spam over internet telephony and how to deal with it. 2011.
[11] Ahmed Khaled Saeed Metwally. Voip using java. Bachelor Thesis, page 0, 2014.
[12] Richard Parsons. Voip congestion management - basic queuing methods. TIP, 2004.
[13] Julije Ivana Pezelj. Voip qos on low speed links. 2012.
[14] Vasily Prokopov and Oleksii Chyrkov. Eavesdropping on encrypted voip conversa-
tions: phrase spotting attack and defense approaches. 2011.
[15] M Raﬁque, M Akbar, and Muddassar Farooq. Evaluating dos attacks against sip-
based voip systems. 2008.
[16] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,
M. Handley, and E. Schooler. Sip: Session initiation protocol. Request for Comments,
2002.
77

BIBLIOGRAPHY 78
[17] Matthew Ruck. Top ten security issues with voice over ip (voip). designData, 1:0,
2010.
[18] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson . Rtp: A transport protocol
for real-time applications. Request for Comments, 2003.
[19] VLC Staﬀ. Vlc download statistics. https://videolan.org/vlc/stats/downloads.html,
2014.
[20] Charles Wright, Lucas Ballard, Scott Coull, Fabian Monrose, and Gerald Masson.
Uncovering spoken phrases in encrypted voice over ip conversations. 2010.

Challenges in VoIP Systems - Mostafa Ahmed Mostafa El Beheiry - First Draft Final

More Related Content

What's hot

Viewers also liked

Similar to Challenges in VoIP Systems - Mostafa Ahmed Mostafa El Beheiry - First Draft Final

Challenges in VoIP Systems - Mostafa Ahmed Mostafa El Beheiry - First Draft Final