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 Beheiry3 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 workthroughout 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 toexpress it as I envisioned it and not holding me back from putting in as much in itas 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 academicand only had the interest of this work in mind.

I would also like to thank Dr. Hisham for the vision he has about VoIP Systemsand how important they are to advance in this country, and in turn giving me theopportunity to be a building block and hopefully benefit humanity in our neverending quest for science.

Ahmed Khaled, for his work on VoIP using Java, we explored this thing together and uncoveredthe magics that make it work together, and without your work I would not have atrustworthy application for my simulation.

I thank him for calling me day by day, keeping me up to date with his exploits andfor understanding all the point of criticism I leveled at his work.

The days we spent on the fixing the server were some of the most frustrating andmemorable days I’ve ever spent of a project, but we pulled through somehow, andthanks 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 inme and knowing that I can make use of every single penny spent on my educationallife. I can’t begin to express the gratitude. And thanks for giving me a multitudeof solutions to overcome the lack of electricity in these trying times. I love you guysfrom 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 whatwas thought to be fiction. But with great prgress come great challenges, the developmentof VoIP Systems is no different. This work is a collection, categorization and examinationof some of VoIP’s greatest challenges. This work has identified four main categories ofissues, Security, Quality, Dependency, Emergency and how they came to be during thedevelopment of VoIP Systems. Their impact on Voice over IP (VoIP) Systems, whetheror not these issues are crippling to VoIP Systems. Included also are illustrations of thevarious issues, for visualization purposes. A real time simulation of a singled out issueis also included in this work. Finally, this work will also look into possible solutions ifpresent, 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, PacketSniffers, Distributed Distributed Denial of Service (DDoS) Attacks, Eavesdropping, Spamover IP Telephony (SPIT) Attacks, Difficulties with Firewalls and Operating System andNetwork, 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 abase [11], and using OfficeSIP as a server.

IV

Contents

Acknowledgements III

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Aim of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 42.1 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 SIP Invite Request . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Message Method Extension . . . . . . . . . . . . . . . . . . . . . 72.1.3 SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Real Time Protocol (RTP) . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Network Address Translators (NAT) . . . . . . . . . . . . . . . . . . . . 112.5 VideoLAN Client (VLC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Own Work 133.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Packet Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.2 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 Distributed Denial of Service (DDoS) . . . . . . . . . . . . . . . . 193.1.4 Spam over IP Telephony (SPIT) . . . . . . . . . . . . . . . . . . . 213.1.5 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.1.6 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.1 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.2 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.3 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.4 Low Speed Links . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.1 Power Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2 Internet Dependacy . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4 Emergency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

V

4 SPIT Simulation 414.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.1 Failed Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.2 OfficeSIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.1 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.2 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Conclusion and Future Work 525.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 Packet Sniffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.2 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.3 DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.4 SPIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.1.5 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.6 OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2.1 Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2.2 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2.3 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2.4 Low Speed Links . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.3 Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.3.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.3.2 Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4 Emergency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5 Last Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Appendix 60

A Lists 61List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65List 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, andhis 1835 invention of the Morse Code. An invention which Morse used to develop theworlds first long distance means of communication, the Electric Telegraph Line. 41 yearslater humanity saw its second leap, as Scottish inventor Alexander Graham Bell alongwith 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 longdistance 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 inheritfundamental weaknesses from all of its ancestors. Issues of Security passed down fromthe telephone are present, as well as issues of Quality introduced from its usage of theInternet. However, issues passed down such as these are not the only concern for VoIPSystems, certain Dependencies along with the absence of a way to place an EmergencyCall are all challenges VoIP Systems are faced with if they are to progress as the primemethod of long distance communication.

1

CHAPTER 1. INTRODUCTION 2

1.1 Motivation

Since the early 2000s VoIP Systems have seen major developments, and major widespreadusage. Since then, efforts were made into reviewing and refining VoIP systems, countlesspapers have been written detailing flaws, suggesting solutions, or merely documentingthe 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 canbe 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 forfuture 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 specific challenge facing VoIP Systems, butrather 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 bediscussed, the categories are Security, Quality, Dependency, and Emergency.

The Security issues which will be discussed in this work are six, the Quality issuesfour, the Dependency three and a single Emergency issue will be discussed. Section 4 isdivided into four chapters, each tackling a category as described above. Each chapter isdivided into as many subsection as there are topics to be discussed. As for how the topicswill be discussed, each topic will contain four major points of discussion. The origin ofthe issue, and how it came to be during the development of VoIP Systems. Its impact onVoIP Systems, the extent of how crippling it can be to a VoIP System, which is also itsimportance. Solvability, whether or not this problem has been solved, can be solved, oreven merits a solution. In the case of there not being a solution, and the issue meritingone, 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, Difficulties with Firewallsand Operating System and Network.

The four Quality issues discussed are, Bandwidth, Codecs, Queuing, and Low-SpeedLinks.

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 EmergencyCalls. Which is a real concern if VoIP systems are to be considered as a real replacementfor modern day telephones.

Chapter 2

Background

The most notable work around the subject matter of Challenges in VoIP Systems as ageneral 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 ofService (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 wenton to focus its efforts on SPIT.

Although a much more in depth, concentrated and well-rounded effort has been madeby Fraunhofer Institute for Secure Information Technologys Rachid El Khayari. His ownwork of SPAM over Internet Telephony and how to deal with it, has heavily influencedthis own works section concerning the subject matter[10].

DDoS, has been worked on in the title Evaluating DoS Attacks Against SIP-BasedVoIP Systems written by the collaborated efforts of M. Zubair Rafique, M. Ali Akbarand Muddassar Farooq. The authors themselves have stated; ”The purpose of our studyis to help both VoIP vendors and academia better understand different vulnerabilities inthe 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 theirpaper has been merely the Evaluation of DDoS attacks.

Challenges in Securing Voice over IP and Top Ten Security Issues VoIP, covered theremainder of the topics adequately and have been extensively read before attempting thispaper [17].

What follows is an explanation of any and all technologies used in this paper, detailingall 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 sectionalong with the relevant issues for which each technology is linked. Also Wireshark andVLC, which are softwares, have been mentioned in this chapter as they were used in afew specific 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 InitiationProtocol (SIP) will be discussed.

Developed by Internet Engineering Task Force (IETF), it acts as the primary core forVoIP Systems[16]. Of which many variants have been derived with the aim and goal offurther developing the protocol beyond its weaknesses.

It is a signaling protocol, its tasks are restricted to initiating, maintaining, and closingthe VoIP Call. It has become an industry standard which becomes its greatest strengthand weakness. Strength, in that any SIP based client can communicate with another SIPbased client disregarding most hindering factors. Weakness, in the fact that anyone canmanipulate or extract information from most SIP packets, valuable information at that.

Two of the greatest offenders of this weakness are the Invite Request, and the MessageMethod. These will be extensively referenced in the coming chapters thus an explanationof 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 requesttaken from IETFs own documentation of SIP.[16, 11] What is primarily a concern in thiswork is the fact that this request contains the IP Addresses of the person receiving thecall and the person initiating it. It also shows the version of SIP used, the transportationprotocol used and the server handling the call.

The availability of these facts in the Invite Request is an important fact to take intoconsideration for the coming chapters, as most of the weaknesses of SIP lay in the factthat 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 aVoIP application such as Skype with a text chat feature, or an internal company systemwith VoIP phones with SIP Messaging Service (SMS) enabled.

Since SIP is in nature a signaling protocol as mentioned is section 2.1, it can onlyever send request or response messages, the extension handles messaging in a way IETFdescribed as; ”using a metaphor similar to that of a two-way pager or SMS enabledhandset” [2, 2]

Hence, staying true to SIPs nature, the way Instant Messaging (IM) is done is bysending a request using the Message Method which contains the deliverable message inthe body of the Request Message sent. Also, since it is a Request Message the receivermust 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 IETFDocumentation. Some codes have been removed for sake of remaining concise to thegoal. Continued on page 8

1xx Provisional100 Trying180 Ringing

199EarlyDialog Terminated

Table 2.1: Provisional SIP Codes

2xx Successful200 OK202 Accepted (Deprecated)204 No Notification

Table 2.2: Successful SIP Codes


3xx Redirection300 Multiple Choices301 Moved Permanently302 Moved Temporarily305 Use Proxy380 Alternative Service

Table 2.3: Redirect SIP Codes

4xx Request Failure400 Bad Request401 Unauthorized402 Payment Required403 Forbidden404 Not Found494 Security Agreement Required

Table 2.4: Failure SIP Codes

5xx Server Failure

500ServerInternal Error

501NotImplemented

502BadGateway

503ServiceUnavailable

504ServerTime-out

Table 2.5: Server Failure SIP Codes

6xx Global Failures600 Busy Everywhere603 Decline604 Does Not Exist Anywhere606 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 speechsample 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 andtrailer 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 theLocal Area Network (LAN) Media Access Control (MAC) addresses of the devices it isbeing transferred to and from. The IP Header holds the to and from IP Adresses alongwith some control information. The UDP Header carries the portnumbers of the sendingand receiving devices. The digitized voice filed can carry anything from 10 to 320 bytesof voice[18].


2.3 Wireshark

The Open Sourced nature of Internet development has made a tool such as Wiresharkavailable, primarily it functions as a traffic analysis tool, but its abilities go much furtherthan 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 computerwould reveal the packets being sent to and from that computer. With the luxury of mostof the industry standard protocols being open sourced, such as SIP, Wireshark has beenable to integrate a truly deep method of inspecting each and every packet rushing alongits 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 amongstothers. Boasting filters for over a hundred protocols one could argue it is too powerful atool 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 isespecially capable in this field. Aided by the ability to capture a stream of data and notonly 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 networkanalysis 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 througha router function. This occurs by dividing the networks into a stub for which the routercan assign the same addresses assigned in other stubs.

Figure Figure 2.5 depicts an operational network in which NAT is used, as is takenfrom 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 EcoleCentrale Paris students and began as a purely academic endeavor is now a media playermanaged by the VideoLAN Non-profit organization. Amassing over 1.3 billion downloadsfor Windows and OSX alone[19].

It is arguably the strongest media player in the industry, in which it does not simplyretrieve a file from the Hard Disk Drive (HDD). The various methods of input are itsgreatest strength and above all the various ways in which it can receive content is whattruly 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), DigitaleTV, 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 onall 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 PartnershipProject (3GP), Ogging (OGG)/OGG Movie (OGM)/Annodex, Matroska Video (MKV),Real, Waveform Audio File Format (WAV), Raw Audio, Raw DV, Free Lossless AudioCodec (FLAC), Flash Video (FLV), Material eXchange Format (MXF), Nut, MusicalInstrument 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 informationabout the four categories of challenges facing VoIP Systems. First a brief introductionto 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 systemsfall under this category, this is due to its inheritance coming from the very first form oflong distance communication to the modern day telephone and the advancement of theInternet.

Quality, if you are sure your call is one hundred percent secure, yet you cannot hearor make sense of the audio stream you are receiving then the call is as flawed as if it wasnot secure. Perhaps even more so, quality issues come right after security and owe alltheir existence to how the Internet has developed.

Dependency, during a power-cut the traditional telephone is still usable, so long asthe call centre that is being connected to remains intact. However, VoIP Systems findthemselves much more reliant on electricity than the telephone. As far as the developmentof 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. Virtuallyno papers in the field have been written with the goal of addressing this issue, which issurprising since this is a great disadvantage to using a VoIP System at office or in Mobilesover relying on traditional systems.

As mentioned in section 1.2, the issues are more than the ones mentioned in thispaper, and hence there will be justification as to why each issue was chosen, this wouldalso be a suitable time to explain further the structure of each issue and how it will bedealt with.

Origin, of the issue will be the first focal point of discussion, in many papers the issuesare directly talked about with little mention of how they came to be. Which helps inunderstanding 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 fromour past can make the future all that much clearer.

Impact, for an issue to qualify as one that needs discussion its impact needs to bestated, for instance if a DDoS attack can render a call un-place able then it is an issue ofsevere magnitude. However if some Echo in the call makes it difficult to understand thisis less of a major concern. It is still a concern which affects the quality of the service, butit is not as concerning as the service being up altogether. To further seek consistency inhow 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 referenceand a base over which future studies could be placed, and this part of the discussion isessential to this goal. The issues chosen were done favoring the impact of the issue onVoIP Systems, regardless of whether or not this issue has been solved or not. If the issuehas been solved under a credible reference it will be mentioned, if not then a suggestionon how it could be solved will be written. If the solution exists but is controversialthen both conditions will occur, hence these are not mutual exclusive conditions. TheSolvability 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 thesolutions 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, eachmain category consisting of, Security, Quality, Dependency and Emergency, will have asubsection of issues. Taking the security for example, the first issue of Packet Snifferswill 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, whereelectric telegraphs and Morse Code messages could be intercepted along their route andinterpreted, so too could SIP Messages be intercepted and as mentioned in Sections 2.1.1and 2.1.2, these messages contain much and more than what a telegraph could havecontained. As any person tapping into a telephone central could monitor the calls of acertain telephone, so could VoIP Traffic be hijacked and played over a program such asVLC.

The similarities between flaws of both systems are staggering and many, but themethods 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 bymany nodes and stops in along the way. Similarly a phone call needs to pass through thecables, to the Call Centre and to the callee. Packet Sniffing has its roots from tappinginto phone calls, as someone would tap into the call centre and monitor any calls comingfrom a certain line or to a certain line. The person tapping into the phone call couldlisten 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 nowheard the phone call, and knows whatever information has been exchanged during thatconversation.

The same is viable to do using Wireshark, which as explained has the necessary toolkitto monitor all incoming and outgoing traffic over a certain device. And as mentionedbefore in Sections 2.1.1 and 2.1.2, this means that a simple run of Wireshark can, andwill 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 isbeing 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 veryexposed position, which can easily be retrieved by the intruder. Making it merely a caseof 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, andimmediately the magnitude of the issue is made obvious. The IP Address of 107 alongwith 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 asignaling protocol the Invite Request needs a Response. However, the response will alsobe sniffed, and the sniffer would now know not only who attempted to call who, but thestate 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 apparentto the intruder. An argument could be made that this is not worrisome in VoIP Systemssince they are primarily focused with Voice, but many newer systems come with SMSEnabled devices, and in the case of Skype, it is built around the notion of chatting in thefirst place.

The reason why Packet Sniffing is placed amongst the highest on the impact charts issimple. If a call is denied, as in the case of DDoS, there is no information leaked. If a callis breached however, this is another matter entirely. The only real argument that couldbe made is for Eavesdropping as a contender for the most impactful security breech, butEavesdropping is merely an afterthought of Packet Sniffing, Eavesdropping in on its owndoes not reveal IP Addresses nor reveal chat messages, and hence Packet Sniffing wasranked 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 liesin many ways. To stop a person from tapping into a telephone line at the telephonecentre, it would seem easier to restrict access of people with no security clearance in saidcentre. Another solution for those who thought they were under surveillance and did notwant anyone to know what they were saying was to speak in cyphers, hence the contentof 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 anyand all access to the network, which becomes increasingly difficult the bigger the networkgrows and the more people begin using it. Hence a further security measure could beadded, speak in cyphers. Or rather, encrypt the SIP packets so they would not be aseasy to gain access to their contents.

Secure SIP (SIPS) aims to do just that, to correct the security flaws of SIP, insteadof sending packets of UDP and TCP. It uses Transport Layer Security (TLS) which is anewer iteration of Secure Sockets Layer (SSL).

There is however a flaw with this solution, there is a trade-off between security andavailability which must be understood. What makes SIP popular is its compatibility withall systems, in order to begin using SIPS there arises a need to make sure the devices inquestion 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 intelligentbrother. To provide context and follow up on this analogy, Packet Sniffing is moreintelligent 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 howto use. Eavesdropping however merely plays out or outputs a conversation, making ithypothetically no different from phone tapping.

To note, this section deals with Eavesdropping as a standalone issue, there are toolsavailable for eavesdropping on a certain connection, attempting to pick up any UDPPackets and play them, regardless of IP Address. While the more classical way of viewingeavesdropping is that it is a level above Packet Sniffing, this work has the notion of theopposite. 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 similarityto Packet Sniffing, yet it remains a different topic. Hence for interest of eliminatingrepetitiveness this chapter will remain shorter.

Impact

”It is said that if you know your enemies and know yourself, you will not be imperiled ina 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 owncalls 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 theconversation, so for instance if used in espionage or in tyrannous countries could havesevere 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. Inorder to encrypt a VoIP Call without losing time to encryption it is also compressedwith Variable Bit Rate (VBR) to shorten the sending time. However, recent studies haveshown that the language of the audio being compressed could be accurately achieved fromthe encrypted stream. This, along with searching for a single phrase it has been provenwith over fifty percent accuracy to be successfully able to identify whether an encryptedstream contained a certain phrase or not. Which calls in question the true strength ofthese 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 analogyof sorts. If a post man on average under normal circumstances has to deliver 1000 lettersper day, and on a certain day he receives 100,000 letters to deliver. There is virtuallylittle this man can do to distribute 100x his normal workload. It also comes as no surpriseto the postman when he opens these letters and finds than 99,000 of them are empty andfrom the same person. This type of attack did not occur due to the cost and effort neededto launch such a massive attack, numbers aside.

However, in a hypothetical word, where there was only one very fast postman, butpaper was free, and stamps were unlimited, such an attack could still be feasible, andthis 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 developedinto 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 300Gbps 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 issimply more to be gained from allowing a call to go through and knowing what was saidthan 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 inCyber Warfare. Everything from Governments to Gaming Companies have been at onepoint in time been the target of DDoS Attacks, of various magnitudes.

Recent researches [15] have shown that, while SIP Servers vary from robustness andat which point they reach a contrived Breaking Point, all of the servers available for usetoday 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 sendinvite 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 thefirst place.

This is a very solid potential for future work, if not the solutions mentioned but thesubject matter itself, as said above DDoS attacks are only getting stronger, so it is onlynatural for the next focus of research to concern surefire ways of defending against DDoSattacks.

To shed further light on the severity of the issue, companies dedicated to ”CloudBased 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 13thof April, and Bob wants to stop Carl from answering this call, a valid way of doing thisis repetitively calling Carl and hence making it seem for Alice that Bob is busy. This iswhat 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 themall 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 ordeclined. 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 whichdirectly arrives to the user. E-Mails are also much easier to analyze, they give room foranalysis with the information they carry, yet a SPIT call cannot be determine pre-handfor it arrives as a regular call would.

SPIT faced a difficulty in its definition, but recently it is being agreed on the definitionof: ”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 communicationssession. 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 anentire server unusable, SPIT attacks only target bulks of people. To perform a SPITattack, the VoIP network is scanned and information regarding the IPs of the users onthe network is gathered. Afterwards attempts to establish calls with as much of theseusers 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 addressesaccused with SPIT in a blacklist is impractical at best.

A method of dealing with SPAM, or rather unwanted automation over the Internetin general is Completely Automated Public Turing test to tell Completely AutomatedPublic Turing test to tell Computers and HumansApart (CAPTCHA) but even this canbe worked around by performing a CAPTCHA Relay Attack, by relaying it to humansolvers.


Also an IDS does not seem as viable here as it would in a DDoS Attack, even though itdoes seem as if the IDS can identify a SPIT IP by the rate of calls it places and abnormalbehavior it displays there is still a way around it. The attacker could simply adjust thecall rate randomly, making it more difficult 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 IdentityHijack, Call Rate Adapt and Account Switch, will in the end be able to breech mostpresent 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 couldnonetheless find ways to bypass countermeasures, without even exploiting SIP protocolweaknesses or deploy methods of lower layer protocols. This showed us, that in order tomitigate threats like SPAM over Internet Telephony, developers and administrators needto challenge their solutions.

More research in this issue is a must, an explosion in these types of attacks can verywell 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. OlderFirewalls predate SIP entirely, or did not anticipate the need to let SIP Messages passunhindered, making for blocked SIP Messages entirely.

Yet, even with new firewalls VoIP systems seemed to struggle to preform, as the newerfirewalls put more emphasis on security over all else, and when a firewall finds a massof RTP packets wanting to pass through, it will feel compelled to check each and everyone. Causing an unsettling delay in the call, and in lower end computers possibly jitteras well.

The last origin of issues with reach-ability stems from the impending depletion of IPv4addresses, and the short term solution of NAT, as was described in Section 2.3, alongwith how SIP Messages are constructed[9].

Since the internal IP Address is different from the Public IP Address the SIP messageleaving the network will hold the wrong internal IP Address and not the Public IP andPort.

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 alongthe way. This is however an issue with the setup of the system and has a multitude ofsolutions.

Solvability

Simply using a NAT Box to change the IP Payload of the SIP packets would be enoughto solve this issue. This would allow for a simple change of the IP to the correct Publicand Port variant.

Application Level NATing could be also considered by adding an Application awaregateway 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 thepacket and hence decrypt the packet, meaning that this solutions defeats the purpose ofencryption.

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 itwould 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 willingto set foot in the field, and a fundamentally correct one at that. Until this point thecontention has been over abusing VoIPs inherent weaknesses, looking at the weaknessesof an Operating System such as Windows however brings up a new host of other securityissues 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 bekeyloggers or sniffing utilities, basing a VoIP on an OS such as windows only makes itthat much easier for intruders to attack the system.

Solvability

Cisco, a leading developer in the industry have long since migrated their systems andservices to a Linux based OS, and the same is advised for any VoIP System willing tomaintain a semblance of security.


3.2 Quality

Assuming all issues of securing VoIP Systems are done with, and a perfectly secure VoIPSystem is created. The first issue this hypothetical system is going to have is a concernfor the quality of the calls in this system. Security does not come without a price, in thiscase quality is favored over security or reliability. For instance, the media packets sentare traditionally done using UDP, and while TCP is known to be the more reliable wayof 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 representativeof better security measures, but the way they secure the network might lead to horribledelays.

To return to real world analogies an argument can be made to relate between packetstraveling in coaxial Ethernet cables, and people traveling around the roads. Bringing thisargument to its bare bones, transportation is in essence an layer on which communicationwas built. In order to get a message across , there must first be a way to get this messageacross. 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 packetthrough cables, and the traveling cargo through roads. To achieve security when thecargo 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 sendingdata you wish to encrypt or protect over the Internet. The encryption on the data moreoften 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 atremendous amount of files. To return to the analogy, a metropolis has crowded streetsbecause of the same reason. The bandwidth available to any certain user can be comparedto 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 mentionwhat has already been said above. And hence the coming subsections will tackle each ofthe 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 bandwidthavailable, 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 sendsa single voice packet every 10 to 40 ms. This can be either compressed, uncompressed orencrypted. RTP will send the same number of packets regardless. It can take anywherefrom ten to a hundred packets to carry a single word using this standard system in thebest 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 possiblefor the quality to remain at an adequate level. As the size of the packet decreases the timeit takes to create and send it go down proportionally to it. Yet the need for bandwidthrelates with inverse proportionality to the size of the packet. The smaller the packet, themore packets are sent, and the bigger the packet overhead becomes.

The issue with long packets however is that they are being sent over UDP, meaningthat 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 inquestion, meaning that in a single second a total of about 50 packets are sent, and asmentioned 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 digitizedvoice field alone.

Impact

” In reality, there is no Voice over IP. It is really voice over RTP, over UDP, over IPand usually over Ethernet. The headers and trailers are required fields for the networksto carry the packets. The header and trailer overhead can be called the shipping andhandling 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 andheader contribute with 18 bytes overhead. A total of 58 bytes of overhead are generatedoutside of any voice bytes in the packet, this can account for 80 to 20 percent of thebandwidth used in a VoIP call. This is in a single packet, and this shows how inefficientshorter packets are in contrast to longer ones. And this is all before any encryption isadded. [1]

From the above discussion we can conclude that the bandwidth consumption of a VoIPcall relies on, Compression Techniques used, Packet Overheads, and Network Protocolused.


Solvability

An issue such as this has indeed attained a significant amount of attention and for themost part can be considered solvable, with various applicable solutions.

The first of which would be compressing voice in the RTP packets, which in the endmakes up the majority of the bandwidth usage. Which is how Codecs came by, and willbe discussed in depth in the coming section.

However compressing voice comes at a price and creates an interesting trade off whichneeds to be taken into consideration. The lower the size of the file the easier it is tosend and the smaller the delay, however compression in essence usually involves a loss ofdata. Hence in order to better the quality of a call for a low bandwidth link, it couldbe that the quality is being brought down in terms of the actual call itself. Also, whilecompression decreases the delay in sending the packet it does create a sort of processingdelay to compress the packet in the first place.

Strategies on choosing a certain codec will be discussed in the coming section, thissection could be considered as an introductory section to the coming one, or the cominga supplementary section to this[1].

Figure 3.7: Bandwidth Calculation

Another way to manage this issue, is to allocate bandwidth where possible to VoIPcalls alone. This can be attained by calculating the bandwidth needed by the system andreserving 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 anytype of vehicle to pass over them. Some are rougher and require tougher more durablevehicles 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 ofnavigating it. The same is true to Internet connections. A dial-up connection cannotbe expected to offer the same level of quality that an Asymmetric digital subscriberline (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 wereusing became saturated with cables. In the 1950s however a technique was created bythe American ATnT communications company which allowed for a single copper wire tohold more than a single call, by digitizing the previously analog speech they managed toachieve 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 timeoperating at 8 64 Kbps, and while it is not regularly applied to LAN connections, thisshowcases how compression can be useful at any range, hence CODECs were created tochoose based on the bandwidth available, the appropriate compression.

Impact

The word CODEC, comes from the essential parts on compressing a speech signal, whichare: COding, and DECoding. The impact of CODECs has been discussed extensively inthe 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 choosingthe proper CODEC for a certain VoIP System. As mentioned this depends primarily onthe 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 theavailable codecs, a good VoIP System can dynamically change the codec to use for eachcall.

For instance, if the network is congested at peak time, a lower quality codec shouldbe used to compensate for the lack of available bandwidth, and on the other hand, duringlow 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 theirwebsite 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 qualityspeech by delivering analog sound range of 7kHz as opposed to the 3.4kHz by itsG.711 counterpart.

G.723.1, reduces bandwidth consumption greatly but the speech is noticeably poorer thanits 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 figure 3.9 takenfrom 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 ofQoS is prioritizing which traffic moves on and which is delayed based on its classificationor characteristics.

Origin

When dealing with traffic in the real world, very little distinguishment is made, leadingto important cargo being put behind lesser important ones when being processed due tothe 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 thevarious forms of traffic on any given system at any given time, any VoIP System will befaced with the issue of Congestion.

Impact

Simply put, if handled in an improper fashion, congestion will lead to huge amounts oflag inside calls, without proper prioritizing for the packets carrying the voice a propercall would never take place.

Solvability

To solve the issue of congestion and to ensure that the higher priority packets be dealt withimmediately, a series of Queueing Systems were established. This section will highlightfour queuing systems, and their role in VoIP Systems [12].

First In First Out (FIFO), is the first, easiest, and most inefficient method. In realityit is not a real queueing system, it simply transmits by order of arrival.

Priority Queuing (PQ), this method assigns four different priorities for each packetbased on its classification, ranging from High, Medium, Normal, and to Low. Simplyput, when packets are received those in the High Queue are transmitted before those inmedium, and then those in normal and finally those in low. The fundamental flaw in thissystem is that the Low Priority Queue might never be handled if there is an influx of thehigher priorities.

Custom Queueing (CQ), sixteen queues are offered with this method and as with PQthe packets are assigned to these queues based on classification. It operates in a roundrobin and its goal was to stop protocol starvation, this method does however introduce alarge amount of overhead and can prove to be detrimental.

Weighted Fair Queueing (WFQ), dynamically assigns bandwidth to the traffic relianton 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, andhence could make for an undesirable latency.

Out of these queuing methods none fit the needs of a VoIP System, and hence mixingand merging between these methods to create a Hybrid fit for a VoIP System is the bestapproach 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 speedlink? The speeds considered by modern day researches to be slow links range from 56kbps, 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 theconclusion that a well set up person would most likely actively work under a low speedlink.

Impact

What this means however, is that there is little and less bandwidth to provide for whateverwork is being done alongside a VoIP Call, which takes high priority in its share forbandwidth.

This means that not all the VoIP Quality Assurance Parameters are satisfied, delayscould increase the 150ms barrier, jitter extends the 25ms margin, and packet loss exceedsthe maximum allowed.

Solvability

Researches have shown that the methods mentioned in this paper can be enough to dealwith 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 Queuingmethods these results were attained.

For the speeds between 2Mbps and 128kbs, WFQ showed prominence, along withG.711, while the G.728 has shown good performance for all speeds but will be excludedon account of its much lower quality. For the lower links however no form of satisfiableQoS 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 codecfor future use. The research also showed that the main culprit of QoS Degradation inlow 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 tofunction.

In this section, a discussion on VoIP Systems reliance on power will be held, alongsidea 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 willbe held over the other.

3.3.1 Power Dependency

Computers are not designed to run without power, they are in essence, machines whichhandle electric signals in the basic binary form. And so it did not occur to the leadingdevelopers of VoIP Phones that they would need to establish a method to avoid usingpower cables for their Phone sets.

Origin

The very first phones were not developed with smart power consumption or power sourcechoosing in mind, and hence as will all computer related appliances they came with acable. 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 PowerAdapters.

Impact

As with anything that involves power cables, a simple cut in electricity will render theentire 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 froma 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 tothe Switch, and from the switch the adapter will send both power and connectivity tothe VoIP Phone.

This makes it much easier to maintain communications by keeping the Switches on abackup 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 bringup none the less.

As with regular phones which are dependant on their connection to the PSTN, VoIPPhones are dependant on their connection to whatever outlet they should be connectedto. Whether it be a WAN connection, or a Local one, should the connection be severedthe 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 lastchallenge facing VoIP in general.

”The ability to access emergency services by dialing 911 is a vital component of publicsafety and emergency preparedness. It is imperative that consumers of telephone servicebe 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 ownwebsite, which is responsible for moderating the standards of communications in theUnited States of America.

Origin

As with the power dependency issue, VoIP Systems were initially created as a way tohave vocal exchanges over the Internet or over LAN. It was not initially developed withthe mindset of defeating PSTN Telephones.

People simply aspire to use the most cost efficient methods possible to them, andhence VoIP Systems were brought into contention with PSTN Telephones.

The way 911 calls operate is solely through the PSTN, and so it would seem thatall LAN VoIP Systems would not have the remote ability to contact 911, or even VoIPSystems in general.

Other than this, traditional phones have a specific phone number linked to a specificfixed address, and so upon reaching 911 Emergency Call, the location is quickly identifiedand aid can be quickly offered.

However in VoIP Systems a single user can connect from virtually anywhere if theservice allows it, whether it be from home or in office. This portability raises manychallenges 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. Forinstance in the office where there probably is a normal telephone in the vicinity it willnot be as big an issue as in a corporate building which focuses its communications soleyon VoIP.

Aside from the impact in reality, this issue is a defying block between VoIP Systemschance at eclipsing PSTN phones. And so in order for VoIP Systems to progress anddevelop 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 hinderanceaffected VoIPs development. Other people saw opportunity in this situation and createdVoIP 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 rerouted via the phone system to Northern911s Servers where they would handle the calland use the standard PSTN Technology to reach the distressed users local 911 serviceand hence solving the issue, although this does entirely depend on the availability ofNorthern911s Servers and Employees.

The more practical approach as was required by the FCC, was to Interconnect VoIPSystems to the PSTN. This was required of all VoIP Providers who want to sell theirservices to as many people as possible, and hence allowing the VoIP User to connectthrough 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 issuesraised by this work. Collaboration with Ahmed Khaled Saad Metwally took place, inwhich this work and his merged for mutual benefit.[11]

A Running VoIP System was needed in order to present the chosen topic, whichin order to present at peak capacity needed to be restrained to a single topic, as wassuggested.

For the topic, SPIT Attacks were chosen, since it is a good basis for future work, andcan be underestimated by the majority of people. A demonstration in the true power ofSPIT even on a local scale should reveal the fact that it is a real threat that will rear itsface 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 theconclusion to collaborate and use Ahmed Khaled’s VoIP System using Java would be thesafest and best option available. After having already build the client, the collaborationtook 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 bementioned 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 distributionsavailable at the time was Ubuntu, which was run over Oracle’s Virtual Machine. Hencethe 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 compatibilityissues with Windows 8 for 3CX, and after Asterisk began showing promising signs, thesetwo 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 didnot run under the available Linux distribution, after attempting install Kamailio from theUbuntu Application Manager, as well as manual installation to compilation from sourcecode, Kamailio and reSIProcate proved to be too difficult to set up, which contradictstheir advertisement of being easy and fast to set up.

Going back to Windows based servers, OfficeSIP was first tested but the responsecodes seemed to be off and so was abandoned prematurely. A variety of SIP Serverscame after, partySIP, MSS, simpleSIP. All of which behaved and reacted in ways thatdirectly opposed the RFC. And hence our work saw a return to OfficeSIP as a last gaspeffort 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 creationof user accounts on the server, and testing their connectivity to the client, results provedto 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 ownthesis. To help out, the GUI was created in collaboration. The following figures willshowcase 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 onthe OfficeSIP server. Hence, the client login screen takes the Server IP Address alongwith a username and a password. It then sends a registration request to the server withthis data (after the authentication process), and connects to the server if a user with thegiven 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 notification to the user of the issue, if theserver itself is not available the application will time out and notify the user of the issueas well.

Figure 4.3: Client Login Screen - Connecting


This then moves the user into a call room, which contains a text box in which theuser 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 usersfrom 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 Modifications

4.3.1 GUI

In the interest of not needing to include a multitude of Figures to showcase the moddedclient, only the important parts or differences between the Vanilla client and the moddedone will be discussed.

The aim of this modded client, is simply to be used when presenting the work, andto 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 theunmodded client is still available for testing purposes, then there is the option to startthe SPIT Attack process, or return to the illustrations for presentation purposes, or toreview not change a few settings.

Figure 4.6b shows the settings available to be reviewed, the server and current IPAddresses 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 stilltakes 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 underattack and what is the current status. Whether the user is listening to Advert1, orAdvert2, 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 thissimulation could be to include which files to be sent, which part of the file is beinglistened to and overall better control on the SPIT Attack.

Figure 4.9: Logout

This simulation simply selects at random from a list of fivepossible adverstimsents and plays them, once the user end thecall it autonomously redials the user and plays another advert atrandom.

The fact that the user will never exit the busy state is whatmakes SPIT dangerous, this means that this user is now virtuallyout of the system.


4.3.2 Code

This section details what was changed in Ahmed Khaled’s Client in technical terms. Tobe noted as a reminder that the client was made entirely in Java and hence the codedisplayed in this chapter is Java code.

For a detailed description on how Ahmed Khaled handled his own client, the reportVOIP 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 arethe ones the attacker needs to concern himself with, such as whether the victim’s phoneis ringing, or whether the call is established and a certain advert is beind played, or ifthe user ended the call and the SPIT attack attempts to redial, or if the user is simplyoffline or is in a call.


client

Listing 4.2: Modified 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 overand over, which simply finds 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 thisexample ringing, it is the same throughout the remainder of the client and will be put inappendix 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 werecreated 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 andchallenges that face VoIP Systems. In an attempt at becoming something of a referencepoint upon which future works could be based upon, and hence a total of 13 topics werediscussed, most of which require yet more investigation.

When considering the title of this work, one should also consider the question ofwhether or not each topic has been solved yet, and if not then what are the proposedsolutions.

In this chapter the summaries of all the proposed solutions will be gathered for easeof 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 andcompatibility depending on the system in question, a casual chat application will needto be more compatible on more devices than a Secret Service Agency would need, andin turn the Agency would prefer to capitalize on the strongest security possible hencedecreasing the amount of devices with the capability of compatibility drastically.

For future work in this matter, the suggestion would be to research for the possibleoptimal level of security to compatibility, for instance creation of a rating system to ratethe security and the compatibility of the VoIP System in terms of encryption and a studyto 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 throwoff the newer methods of realizing a phrase when uttered throughout a call.

This subject, while very specific, is considered fertile ground for future work. Thetwo strongly backed researches mentioned should be read and considered, and to buildon 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 defenceavailable it to mitigate the DDoS attack, high profile targets should look at Cloud BasedMitigation companies, while more middle ranged targets should look to implement anIDS.

The toughest task to tackle due to the ease of its execution but the one in most needof handling.

5.1.4 SPIT

An area of great controversy as there is a vast multitude of solutions available, but allpossess exploitable weaknesses, anyone with the ability to: Device Spoof, SIP IdentitySpoof, 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 mightjust prove too formidable to breech at once.

As VoIP Systems spread this issue will grow with it, future work here would be wellbased on Rachid’s work, and would lead to a direct solution or the confirmation of theneed 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 IETFsSTUN and TURN protocol and server, or follow the path Skype took and write your owncustom protocol along with a relay server.

It could prove to be good practice to develop an open Java Based API to handle theseSTUN 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 moresecurity is what is desired. Moving at least the servers to a Linux based system wouldbe advisable if the VoIP System wishes to sell on Windows. The servers at the very leastneed to be well protected against attacks.

A rarity, but no future work is suggested in this area, unless a massive undertakingof 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 allocatedto 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, dependingon the available bandwidth, for this a calculation of the bandwidth available and thebandwidth needed for a codec to function without causing issues would be needed and isdescribed in Figure 3.7.

5.2.2 Codecs

Figure 3.9 features the most prominent codecs as mentioned by Cisco along with therequired Bandwidth to run each codec. Bearing in mind that not most PCs have all thecodecs installed by default. The way this issue is solved classically would be througha negotiation of codecs before the call starts hence choosing a codec that will functioncorrectly on both bandwidths of the caller and the calee.

As for the most famously used of upcoming codecs, a discussion has been held inSection 3.2.2 concerning each one.

Suggestions for future work in this area involve a way to negotiate and install codecsbased purely on the bandwidth at runtime. Or a simple deep research into the availablecodecs, 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 simplesolution. 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 VoIPTraffic could unfold new and better ways to direct VoIP Traffic, but will require a goodamount of knowledge in the subject matter. And while the different queueing algorithmscould indeed be simulated, testing in real time would require access to a programablerouter.


5.2.4 Low Speed Links

The current solutions for Low Speed Links are not satisfactory, yet research in the matteris not considered to be a priority since the world is advancing in terms of speed andquality 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 couldbenefit 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 connectionsneeded in the VoIP network significantly, if for instance a wire could be developed thatcarried PoE without the need for this adapter entirely, then this would eliminate a fewof these issues.

Future work in this certain field is not encouraged as it is purely hardware focused andalready in development, however if this were to be pursued then a more abstract topiccould open up, the possibility of sending power over wireless has been long discussed and itwould 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 systemdetects the downed connection and switches to a buffer mode. In which calls from thecaller 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 obvioussolutions. Either connect to a private agency which handles the call for the VoIP Systemdepending on the location. Or interconnect the VoIP System with the PSTN so that theemergency 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 asingle issue, or discuss it in depth. This works aims to be a staple for future works tocome, the topic of VoIP Systems is an uprising topic, and one which could soon changemuch of how we communicate.

Much development has gone into this topic, yet the articles about the challenges facingit are not nearly as well rounded as need be. What this work claims to be, is a referencepoint 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 statusof VoIP Systems, how far we’ve come, the problems that have spawned since the earlydays of VoIP Systems, how they originated, how sever they could be, and finally howthey could be solved.

Appendix

60

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 andHumansApart

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 Influence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.9 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.10 Cisco VoIP Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.11 PoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.12 VoIP Emergency Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 OfficeSIP 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 Sniffing 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 refrencedin 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, tobe noted that it is mostly interactive yet having them in the paper could prove to bebeneficial.

Figure C.1: Packet Sniffing 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. Sipmessage 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 forComments, 1994.

[7] FederalCommunicationsCommission. Voip and 911 service. 2005.

[8] Nick Galea. The main sip invite header fields 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 Rafique, 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 protocolfor real-time applications. Request for Comments, 2003.

[19] VLC Staff. 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.

Documents

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