Conceptual Design Framework For Sample VoIP Project Information Technology Essay

Published: November 30, 2015 Words: 4298

Based on literature sources discussed in previous chapters, we will summarize our knowledge on a conceptual design framework, for a sample VoIP Project.

Basic Components of VoIP Infrastructure: 1)Router devices 2)Switch devices 3)Load balancing devices (All LAN devices based on Ch 2.2) 4)Firewall devices 5)Virtual Private Networks (VPN's) (All security devices based on Ch 2.2) 6)Call Server 7)Gateway 8)MCU 9)Ethernet Switch 10)Routers (Other components)

As per (Ch 2.5), it is prudent to arrange the components, as per cross-layered architecture, for enhanced load balancing, reduced design complexity, and higher modularity, and maintainability, therefore ensuring suitable packet speed, thus en-suring the design is ready for Mobile communications as well.

Type of VoIP Project: For our design purposes, we will examine p2p (peer to peer) VoIP communications, as per (Ch 2.3), since our Simulation experiment will be based on Skype TM, which is a p2p communications tool. Central to a p2p design set's security standards, is an 128-digit AES-based cryptographic algorithm (Ch 2.1), which can be downloaded from http://csrc.nist.gov/publications/ after e-payment. The security operates out of a Public Key Infrastructure platform, e.g. VeriSign TM, which attests digital signatures to all VoIP calls being made (Ch 2.3). A p2p infrastructure also necessitates a standard network protocol, which the data packets can identify. As per (Ch 2.1), we must go for Sessions Initiation Protocol

28

(SIP) which is the most widely-used network protocol. For effective protection against security breaches, the SIP protocol must be under the shield of some network guard, and Juniper TM (Ch 2.8) is a leading authority to provide digital signature authentication for secure SIP voice transactions. In order to smoothen voice quality for SIP protocol, there are some techniques to be kept in mind, called hop by hop authentication techniques (Ch 2.7).

Security framework: Carrier peering, and session border controls are effective in-struments designed to improve upon current security protocols (Ch 2.5). These are provided by network solutions companies, like Sonus TM and Juniper TM. SBC's provide a small range of IP addresses, through which all signal communications must pass. Both these operatives perform some other vital functions desired in VoIP communications 1)Billing, i.e. to generate billing records when a call is completed 2)routing services (8YY translation, ring tones, announcements, and proportional routing). 3)Caller ID etc. We also need appropriate mechanisms to perform NAT traversal functions, e.g. overcoming communication roadblocks like IP tunnel endpoints, markers, proxies, caches, transport relays, modified DNS servers, etc (Ch 2.6).

Improving QoS: Building reliable security infrastructure comes at the cost of de-clined satisfaction in Quality of Service (QoS) for VoIP communications. Here are some appropriate measures designed to improve upon this factor (Ch 2.9):

• Latency: Should be kept between 150 ms- 400 ms (for international calls)

• Jitter: Is regulated using routers with headers, or buffer instruments.

29

For best QoS, enough bandwidth is a must as proved in next page, and broad-band networks should be encouraged. SS7 architecture, and VoWLAN networking are essential for a p2p broadband experience (Ch 2.10). Aruba TM is the biggest name for VoWLAN, whereas Juniper TM is used for designing SS7 architecture.

The main issue of concern in design is, Voice Quality. VoIP is a synchronous and real time application (Qovic, p.1). When it combines with IP, call quality problems may result (Qovic, p.1).

Figure 6: Sample VOIP Network

In considering the totality of VoIP design, we must examine the factors that negatively affect voice quality, and any fault tree analysis, must take a subjective account into the quality of service, being addressed as a central issue. Perceived voice quality is a function of many factors: jitter, delay, echo and packet loss

30

(Qovia, p.4). Jitter and delay have been covered in a previous paragraph. Echo, is caused when hybrid circuits in a telephone network convert between a four-wire circuit, and a two-wire circuit (p.4). Echoing occurs when there is an audible leak between sending and receiving areas. Echo is reduced by physically shorten-ing the distance between the sending and receiving circuits (p.4). In order to quantitatively portray the performance of VOIP modules, it is important to ponder over QoS issues, the following performance table is useful (Qovia, p.5):

Table 2 : Voice Quality Measurement

VoIP deployment: Table 2 will be of great help in the course of Project Simula-tion, in next chapter. Meanwhile, central to design is consideration of proper de-ployment of VoIP. Deployment of new products has always been a great chal-lenge, right from technology officers, to network administrators, They have to bal-ance productivity, with costs, and integrate it with existing infrastructure (Rao, 2004). Other issues to deserve priority, are troubleshooting, teething and compati-bility problems during initial stage, and performance tuning and maintenance later. So, here we discuss different parameters connected with a reliable p2p VoIP de-ployment (Rao, 2004).

• Bandwidth: As voice is more sensitive than data, bandwidth requirements automatically go up. VoIP devices should be configured to use a more bandwidth-intensive codec, such as G.729-A, which can use 87.2 kbps of

31

NEB (Nominal Ethernet Bandwidth). Also, existing traffic patterns on the network should be identified. If it is already congested with a lot of broad-cast traffic, it would definitely affect response time. For best results in p2p communications, it is safer not to merge them with other signals, such as TV and Radio. When deploying VoIP, it is mandatory to have a separate VLAN, which will keep the voice and data networks separate (Juniper's VoWLAN in our case). Coming back to bandwidth, the important design cri-teria is to ascertain the number of simultaneous voice calls that can be made over WAN links (Ch 2.2). For this, compression technique to be used should be known, the payload size of voice packets. Some VoIP cal-culators are available, e.g. in Project Simulation chapter. www.voip-calculator and www.ixiacom.com are VoIP deployment modules available online.

• QoS: Typical toll-quality calls, require at least 16-20 kbps of bandwidth. There are also bandwidth management solutions (Ch 2.9).

• Handling power problems: Unlike regular phones, p2p phones suffer from power outrages. However, a good-built UPS is an effective solution. How-ever, a good bit of power planning from source end is desired, as to how much backup power is needed.

• Security issues: Apart from security mechanisms discussed in the disserta-tion, the network should be subject to routine maintenance, taking regular back-ups, installing anti-virus software, etc. Also, implementing VoIP per-formance analyzers, like "Appmanger 6.0" from NetIQ for smooth functioning of VoIP is a good idea.

• Prerequisites before deployment: 1)At each LAN, network architecture should be such that at least 70% throughput is achieved within 10 msec.

32

2)Round the trip delay of each packet of IP should be no more than 10 msec. 3)Round the trip delay of each packet in LAN and WAN together should not be more than 150 msec.

Thus, we discussed the feasibility of a proposed VoIP design, and the enormous importance to be placed on security installations. Next chapter will deal exces-sively with a safe and secure VoIP software, (Skype), and the strain put by its security paradigm on QoS parameters, e.g. Jitter and Latency.

3.1 VOIP project simulation

Throughout this dissertation, a consistent attempt has been made to study VoIP technology with the aim of working out a feasible Project on an actual scenario. While the previous chapter spelled out details regarding elementary design con-siderations, this chapter will undertake a Simulation exercise around a real VoIP environment, based on a real p2p VoIP software. For our simulation purposes, we will consider Skype. The previous chapter dealt with design background of Skype. Also, in earlier chapters, we dealt with security mechanisms, a great part of which dealt with p2p VoIP software. Before proceeding ahead, it is important to recapture the following essential points of Skype software:

• Skype uses p2p network to overcome the barriers of firewall and NAT tra-versal mechanisms, using routes. The p2p model is different from the cli-ent-server model discussed in (Ch 2.2) and (Ch 2.4) by the fact, that the user directory is decentralized and distributed among nodes in the network,

33

with the end-user nodes (called supernodes) having higher bandwidth, for increasing clarity. The Skype network can scale a user base of 100 million, without the need of a centralized network.

• Skype's code is closed source, using proprietary SIP protocol (Ch 2.8).

• For security procedures, Skype uses 128-bit AES cryptographic algorithm devised by VeriSign (Ch 2.3), and users have to log in using their unique ID's and passwords, and is one of the safest in industry. Skype's window rooms makes extensive use of Carrier Networking and Session Border Controls (SBC's) (Ch 2.5).

For Simulation purposes, we will make real calls using Skype and test its impact on QoS parameters, as well as Lines and Bandwidth requirement for actual field condition, using a VoIP calculator, i.e. for a given packet duration, the number of voice paths permitted for any range of bandwidth. Using data as suggested, we can perform an independent statistical analysis too.

VisualRoute2006, http://www.visualroute.com/index.html is a software that enables determining whether a connectivity problem is due to ISP, the Internet or the Web site being visited, and pinpoints to network where the fault lies. We have used VisualRoute Business edition for checking Skype calls. These are important observations for connectivity with Skype from host server.

34

Hop

%loss

IP Address

Location

Tzone

ms

Network

| 62.216.129.146 |

London, UK

*****

308

FLAG Telecom

| 129.250.10.201 |

Centennial, CO

-7

313

FLAG Telecom

2

10

| 129.250.2.38 |

Centennial, CO

-7

317

| NTT America, Inc. NTTA-129-250 |

| 129.250.2.32 |

Centennial, CO

-7

320

| NTT America, Inc. NTTA-129-250 |

4

10

| 129.250.2.122 |

Centennial, CO

-7

320

| NTT America, Inc. NTTA-129-250 |

5

10

| 129.250.2.237 |

Centennial, CO

-7

317

| NTT America, Inc. NTTA-129-250 |

6

10

| 129.250.16.11 |

Centennial, CO

-7

307

| NTT America, Inc. NTTA-129-250 |

7

10

| 129.250.223.66 |

Centennial, CO

-7

311

| NTT America, Inc. NTTA-129-250 |

8

10

| 198.173.5.35 |

Centennial, CO

-7

299

| NTT America, Inc. NTTA-129-250 |

Table 3 : Observations for connectivity with Skype from host server

As per above observations, the call was made from London, UK to Skype server in Centennial, CO, USA. Note the number of routings (7 et al) utilized before the call connects to main server. As discussed earlier, Skype utilizes these routings for NAT traversal, as well as avoiding firewalls. Also, Skype uses End user hop-by-hop authentication techniques (Ch 2.7), in this case we have 8 hops between London and destination, meaning the call was almost instantaneous. The roundtrip time (latency) to Skype.com, as shown in table, is 299 ms, which is a third of a second. Regarding QoS parameters, packet loss never exceeds 10% as per Ta-ble 2, it falls above 200 ms, which is defined as a fairly stable zone for Interna-tional calls (It should be between 150-400 ms). The jitter is at the most, 100 ms.

35

Chapter 4. RESULTS

The aim of this simulation, was to show Skype is a reliable VoIP mechanism, despite having a credible security infrastructure in place. Indeed, Routing is a very significant method of improving end-user Quality of Service. Considering the security infrastructure laid for Skype calls, the model may be replicated for any Project on VoIP. Next in important scheme of things, lies another round of simu-lation. But, this time we shall utilize the services of what is called VoIP-calculator. http://www.voip-calculator.com/calculator/. There are plenty of parameters within which a VoIP calculator operates, but we will focus our attention on only one, the Erlangs and IP Bandwidth calculator, which quantitatively estimates the number of bandwidths required through an IP based network for a fixed number of voice paths. Using statistical analysis, we will determine if the bandwidth de-sign fulfills a statistical fit of sorts.

Figure 7 : VoIP Calculator

36

As per Figure 7, G.729A is the most common codec compression scheme (Ch 2.1). The frequency with which voice packets are transmitted, have a significant bearing on the bandwidth required. The selection of the packet duration is a compromise between bandwidth and quality. Lower duration requires more band-width, however higher duration means packet loss. So, where do we draw the line. For this reason, we test different calculations for different ranges of packet duration, and arrive at a good ballpark figure, using Statistical means.

A little explanation on different calculator parameters. BHT refers to Busy Hour Traffic, which refers to the number of hours of call traffic during the busiest hour of operation in a telephone system. Blocking refers to the failure of calls due to an insufficient number of calls available. Typically, a figure such as 0.03 would mean that 3 calls out of 100 attempted, have been blocked. Bandwidth is the amount of bandwidth required in Kbps to run the traffic. For optimum compromise between duration, and packet loss, our calculations proceed at packet duration of 30 ms (3 samples). Considering bandwidth is fixed, at Broadband speed of 120 Kbps, we concentrate on other parameters and prepare the table as below. Our ultimate objective is to fine-tune a solution between no. of hours allowed on busy traffic, versus no. of calls dropped in the process.

Busy Hour Traffic

Calls dropped

1.900

0.01

2.250

0.02

2.500

0.03

2.750

0.04

2.950

0.05

3.100

0.06

3.300

0.07

3.450

0.08

3.600

0.09

3.750

0.1

Table 4 : VoIP calculator result at 120 Kbps bandwidth, and 30 ms packet duration

37

For analysis of above Simulation, we will utilize a Statistical software called Mini-tab 14.0 (www.minitab.com) Minitab is a market leader in the field of Statistics. As appears above, there seems to be a lot of correlation between two variables above. Statistically, we verify this claim, and indeed it is true, as the Pearson Correlation coefficient of Busy Hour traffic and calls dropped, comes at 0.991 or 99.1% (Refer Appendix B).

To determine other statistical values, and gather inferences, we perform a sample regression analysis, with Busy Hour Traffic as Predictor (X) variable, and Re-sponse (Y) variable (Refer Appendix C). As per regression analysis done, we have the following results:

Calls dropped = - 0.0915 + 0.0496 x Busy Hour traffic

Also, R-squared value at S-value, comes at 98.1%, which is again a high value.

Thus, both correlation and regression analysis results, point to the fact that the more we clear up network lines to accommodate busy traffic, it also increases proportionately the number of calls dropped, due to obvious increase in packet loss rate due to increased traffic.

In order to statistically determine the optimum number of calls that may be dropped, for achieving our bandwidth versus quality compromise, we perform a Moving average time series test clearly, points 1, 2, 3, 4, 9, 10 fail the test and should not be considered for design criteria.

38

Figure 8 : Moving Average Cell Chart

Thus, for safe design, we can consider any of the points 5, 6, 7, 8 and based on central tendency theorem, we therefore opt for the following design values:

Bandwidth

120 Kbps

Packet loss

10%

packet duration

30 ms (3 samples)

Coding algorithm

G-729 A (8-bit compression)

Busy Hour Traffic

3hours

No. of calls dropped

0.052

Table 5 : Final Design Values for VoIP Project Simulation

Of course with increase in bandwidth, the value "no. of calls dropped" decreases pro-portionately, and broadband connections are therefore, encouraged for VoIP appli-cations.

Chapter 5. CONCLUSION AND FUTURE WORK

5.1 Lessons learned

The major achievements in this dissertation are summarized as follows:

• A blow-by-blow account of every single domain of knowledge that the field of VoIP incorporates; the basics of convergence, inputs from agencies con-nected in different applications of VoIP, e.g. VeriSign, Juniper, NIST, etc., major security initiatives, actual field measurement conditions, Quality of Service issues on security platforms. Design and Project Simulation is based on a strong, yet concise, theoretical background. It is no under-statement to point out that the dissertation has managed to cover ground, on all desired areas of VoIP, drawn heavily from sound academic sources, and is a user-friendly manual for further study, or Project reference.

• A major achievement of this dissertation is, that it is developed along the lines of 13 security questions, gathered from expert agreement (Ch 2.1). These, in turn, form the backbone of Project Design (Ch 2.2), as well as Project Simulation (Ch 3.1). Almost all intermediate chapters have been presented in such a manner, that they support the objectives of the Pro-ject.

• In each chapter dedicated to understanding the particular security issue in question, important solutions are highlighted, to draw learning lessons.

40

• Enterprise and carrier network architecture, featuring routing devices, load balancing devices, switches, firewalls, VPN's (Ch 2.2), media servers, gate-ways, bandwidth managers, edge routers are the first tier of scalable net-work architecture, to be used in laying down VoIP infrastructure. The im-portance of Routing devices in reducing Round trip time for making calls, has been proved in VisualRoute Simulation experiment (Ch 3.1). For en-hanced scalability, cross-layered architecture is a very strong basis for im-proving on factors, such as load balance, better firewall alert, and flexible algorithms (Ch 2.4).

• This dissertation has extensively looked into the phenomenon of peer to peer p2p VoIP communications (Ch 2.3), as opposed to client and server architecture. These operate on a standard instant messaging interface, and are protected using Public Key Infrastructure encryptions. VeriSign, is a leading authority in attesting digital signature to p2p services, like Skype.

• In order to register smooth functioning of VoIP networks, and introduce ad-vanced features, such as call billing, caller ID, translation, ring tones, an-nouncements, etc., many VoIP agencies (not Skype) make use of intercon-necting nodes in their networks, called carrier peering (Ch 2.5), Session Border Controls (SBC's) are used for filtering of a narrow range of IP ad-dresses, and prevent three main security hazards from happening: 1)Denial of Service 2)Theft of network 3)Invasion of Privacy (Ch 2.5).

• Speed is the most significant aspect of VoIP communications. Very few networks can afford delays due to congestion of lines, and providing enough bandwidth, is often not the solution. Many VoIP networks have to wind their way around intermediate middle-boxes, called NAT (Ch 2.6), and

41

from end-user side, there is a necessity for hopping networks. Some hop techniques have been discussed in (Ch 2.7). In VisualRoute simulation ex-periment (Ch 3.1), usage of hops is depicted as a standalone function of improving upon inefficiencies creeping in, into the network.

• This dissertation takes a look into the impact of security infrastructure, on several QoS parameters; latency, jitter, echo and packet loss (Ch 2.9). La-tency is an unavoidable reality in communications, and it can be kept within specification limits (150-400 ms), whereas jitter is non-uniform delay in arrival of packets, and it can be fixed using buffers, router headers and efficient use of bandwidth. (Ch 3.1) simulation deals with this area.

• Like any other communication media, VoIP has its own language protocol, Sessions Initiation Protocol (SIP), although H.323 and other languages are also used. The protocol is subjected to security hazards, and thus, requires to be vouchsafed by an authentication agency, e.g. Juniper Network. The protocol suffers from its own disadvantages, in terms of authorization, au-thentication and accountability.

• Among other security issues, the role of SS7 architecture, and VoWLAN have been detailed in (Ch 2.10). In order to boost network security, inter-connections between nodes is supported by what is known as SS7 archi-tecture (Signaling System 7). The SS7 architecture consists of a high-speed, packet switch network, connected by three types of signaling links; Service Switching Points (SSP), Signal Transfer Points (STP), and Service Control Points (SCP). VoWLAN stands for Voice over Wireless LAN fea-ture, and is applicable in Project Design.

42

• With all available data at our disposal, the chapter on Design (Ch 3) col-lated a sum total of learning lessons for the VoIP project, and a concep-tual framework on a cost-effective, and broadband quality VoIP design, and the essential parameters that would be needed to support the learning. The main themes of design stem from an eclectic combination of the best ideas discussed in previous chapters, and a basic deployment and imple-mentation scheme, and the way the scheme should be carried out. The deployment incorporates the following parameters: troubleshooting, teething and compatibility problems during initial stage, and performance tuning and maintenance later. It identifies G.729 A as the most important bandwidth codec, and 87.2 Kbps as minimum bandwidth needs for reliable VoIP communications, 16-20 Kbps for QoS misalignments, UPS for handling power problems at source, and some elementary prerequisites to be taken care of, before the design can be open to audit. The main purpose of the chapter on design, has been to present a background for next chapter needs.

• The chapter on Project Simulation, (Ch 3.1), is the single most achieve-ment of this dissertation, as it applies core principles gathered from study of the remaining dissertation. As different from the chapter on design, this chapter examines how and why QoS parameters and bandwidth metrics play a role in security-related prerequisites, and must be given due credit. In order to perform real life simulation, a real VoIP service provider was tested for QoS metrics. Skype was chosen because it is currently, the market leader in p2p VoIP communications, and reports drawn from Skype, can be helpful in ascertaining Project benchmarks. The first test consisted

43

of ascertaining QoS parameters during a call made from London, UK to Skype server in CO, USA. The results for latency (round trip time), packet loss, jitter come well within established control limits, and the Simulation experiment serves as an excellent example, of how theory can be applied in practice. During simulation, special mention is made to the fact that all security features adopted by Skype for international calls, are documented.

Apart from QoS, there is a necessity to project the importance of bandwidth studies. For this simulation, we utilize an agency called VoIP Calculator, which quantitatively estimates the total bandwidth required for a given number of voice paths, provided other parameters remain same. The parameters we test in this simulation, include Busy Hour Traffic (BHT) against the number of calls dropped, other parameters remaining same. As evinced from calculator results, there is al-most a linear correlation between the two variables, a fact that is confirmed later by Statistical analysis using both correlation, and regression methods. Statistical analysis is also used to find an optimized value for number of calls dropped, and the combined results, give us a safe set of design values, which is mentioned in table

5.2 Future activity

Since risk assessment on any VoIP project has carried itself off, for around six months, the future course of activity would lie in carrying out an actual "simula-tion" for the Project, and not just computer-based results, which comes only as an exemplary model. It is important to realize how current systems affect field

44

work, and what new systems can be utilized. A little bit on futuristic systems is talked about in (Ch 2.2). Since simulation would be based on proposed methods as spelled out in Design, and lessons learned, the actual parameters will come up during field work for the same. The main functions included would be prepa-ration of environment, server, equipment, software installations and configurations. VoIP is a world-standard application, and in order to meet world-class quality re-quirements, through customer feedback. Actual feedback will be based on fine tuning the system for Project details.

Here is how the proposed Project stands to benefit from the research undertaken for this dissertation:

• In terms of proprietary affiliations, the research looks into several agencies connected with VoIP projects; for instance, VeriSign for PKI attestation and SS7 architecture, Juniper and Sonus for Carrier Networking infrastructure, FIPS for AES algorithms, Aruba for VoWLAN installation. Apart from infra-structure companies, we also are introduced to testing affiliates, e.g. Visu-alRoute, and VoIP-calculator in Simulation module.

• Since SIP will be extensively used in any future Project development, the research has brought some insightful ideas into the fore, regarding the fault areas of that protocol, especially from a security angle. Some other agen-cies have been mentioned in relation to SIP interfaces (Ch 2.8).

• The chapter on design, (Ch 3) covers a featured deployment of VoIP pro-jects, and is useful from the point of view of resource allocation. Special emphasis has been laid in the chapter on the indispensable nature of ele-

45

mentary details, such as bandwidth requirements, QoS framework and se-curity issues mandatory before deployment.

• The Chapter on Simulation, (Ch 3.1) goes one step ahead in consolidating our knowledge on VoIP projects, as it focuses on actual test practice re-sults.

5.3 Prospects for future work

In order to consolidate our total knowledge gains, the research can benefit from complementary modules in other areas, that can aid in the development of VoIP Projects. Laying a VoIP infrastructure requires study of several aspects, closely connected to Project Development. Apart from theoretical foundation of a strong research base, it requires extensive study of Business development, particularly Project Implementation courses. Next in importance lies a core foundation of Le-gal areas; VoIP technology has came in for much criticism in many countries, e.g. China, where government-owned telecom agencies filed lawsuits against ser-vice providers such as Skype, and refused to cooperate because VoIP agencies are able to afford long-distance calls at much cheaper rates (Skype charges $0.021 per minute for any landline calls in the USA and EU). Also, there are concerns over Privacy laws in many countries. Although, Skype is a market ex-ception, there are several VoIP service providers, who've simply jumped on the bandwagon with the boom in this technology spectrum, and a lot of improvement is desired, in terms of providing quality service, within legal framework.