International Journal of Computer Engineering and Technology (IJCET), ISSN 0976INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING & 6367(Print), ISSN

0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME

TECHNOLOGY (IJCET)

ISSN 0976 6367(Print) ISSN 0976 6375(Online) Volume 5, Issue 1, January (2014), pp. 128-140 IAEME: www.iaeme.com/ijcet.asp Journal Impact Factor (2013): 6.1302 (Calculated by GISI) www.jifactor.com

IJCET
IAEME

AIPC : COUNTER-ACTIVE ANALYSIS OF OVERLOAD CONTROL MECHANISM FOR SIP SERVER

Bikash Upadhyay,
1 2

Atul Mishra,

Shraddha Bikash Upadhyay

(Department of IT., BBDNIIT, Dr. Akhilesh Das Nagar, Lucknow, UP., India) (Department of CSE., BBDU, Dr. Akhilesh Das Nagar, Lucknow, UP., India) 3 (Department of CSE, BBDNITM, Dr. Akhilesh Das Nagar, Lucknow, UP., India)

ABSTRACT We have introduced a new mechanism similar to earlier used AIMD algorithm in which there will be a probabilistic change in the sending rate during the overload condition. The probabilistic change will be sender-receiver synchronized by mechanism Additive Increase and Probabilistic Change (AIPC). We show that mechanism is effective, counter-active, reliable and fair. Sender will change its sending rate in accordance with the receivers capacity. Sender-receiver is synchronized such that former reduces the sending rate and the later prevents from being overloaded. Simulation is used to analyze the factors viz. effectiveness, efficiency, fairness and stability. Keywords: SIP, AIPC, AIMD, VoIP, SIP Server, Probability of Rejection. 1. INTRODUCTION SIP is the major protocol used for Multimedia communication such as VoIP. It is an application layer protocol, independent of sub layer protocols (TCP, UDP). SIP is proposed by Internet Engineer Task Force (IETF). SIP works in various phases of call such as Localization of terminal, Analyzing recipient profile and resources, negotiating the type of media & communication parameters and the availability of the correspondent. Its also works out during the call Set-up and Call Follow-up. SIP protocol is a transaction based protocol designed to establish and end media sessions.

128

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME 1.1 EASE OF USE 1.1.1 SIP Overview

Figure 1 SIP is widely being adopted by the IP telephony providers [1], including Vonage and AT&T, as the foundation of large scale deployments. Such providers typically deploy Sip Proxies which are responsible for Call routing operations, assisting request & response, across a larger geographic area to efficiently deal with the increasing sing volumes of traffic. In centralized server architecture, these proxies also deals in authentication and signaling request. The SIP baseline specification RFC 3261 (previously RFC 2543bis) divides SIP Server functionality into the following parts: a. SIP Registrar Serverhandles handles location registration messages. b. SIP Redirect Serverreturns returns contact this address responses. c. SIP Proxy Serverforwards forwards SIP requests and responses. 1.2 Causes of SIP Server Overlaod In SIP server architecture, there are two main rea reasons for performance problem: Firstly, due to the larger network latency between the Proxy & SIP Server (authentication as well) in order to handle the query the authentication requests because the Digest authentication requires a separate request for each authentication operation. Each time a proxy process authenticates a message, it has to wait for the response to continue ue processing the next message. During this time, it cannot process a new request and the requests are rejected. This leads to lower call throughput.

Figure 2 Secondly, with the increase in notable volume of traffic leads to Overload situation. Work done in [5] ] suggests that overload situations not only reduce the performance of a VoIP server but can finally lead to a complete standstill of the complete VoIP service. To withstand sudden increases
129

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME in traffic or temporary lack of resources, SIP servers and Proxies need to implement overload control mechanisms that aim at reducing the work load of these servers and prevent a complete depletion of their resources. 1.3 Measured Parameters for Analysis We used the parameters defined in IETF draft for all the measurements [6], [8]. But we use hardware utilization parameters as well, in order to monitor the performance of memory and resources of the proxies. The parameters are measured based on sender and receiver ends. Call statistics and duration of calls during the message exchange is monitored at the Sender end. Real time protocol samples are also captured as well. At receiver end, Hardware utilization parameters are measured directly. This would include the measurement of memory and resource utilization. The complete list of measured parameters includes: CPU Utilization Memory Utilization Number of Successful calls Number of (Un)Successful calls Request delays 1.4 Categories of SIP Server Overload There are two main categories of SIP Server overload viz. Server-to-Server overload and Client-to-Server overload. In this paper we have adopted the former category. When server capacity is reached and if the server continues to accept requests, application performance and stability can exhausted.

a. Serve- to-Server Overload It occurs when upstream server starts sending substantial amount of traffic (Engineered Traffic E) to the main server (SIP Server, here), pushing it towards overload. We have adopted this scenario for our research in this paper. b. Client-to-Server Overload It occurs when a large number of clients make a simultaneous request not handled by the next server, thereby, putting the server into overload.
2. RELATED WORK Aim of any Overload control mechanism is to reduce the load or burden on the SIP Server. Overload condition is observed as condition in which certain pre-requisite threshold values are exceeded. This leads to dropping or rejection of SIP requests. Work done in [2] analyzes that Performance of SIP Server and VoIP calls during a DoS attack. Quality of Calls is reduced substantially during the attack. Packet loss occurs but can be neglected. A sudden decrease in delay increases with the increase in flooding and stress on SIP server increases. It is also concluded in [6] variation at receiver jitter increases as load on server increases. Detailed analysis of rate based control mechanism [7] suggests that a new class of AIMD algorithm works well during overload condition. Additive increment is decreasing functions of the current sending rate. The congestion control algorithm is globally asymptotically stable and will converge to equilibrium. Mechanism uses a decreasing function of the increase factor and a constant decrease factor. A special case of DAIMD algorithm is considered for various grid based applications. D.Sis [3] proposed R-SOCA which aims at stabilizing the proxy behavior during the overload condition. It prevents the server from being completely exhausted. It takes nature and cause of
130

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME overload together. Dropping and rejecting the incoming request are realized by sending back a 5xx response. AIPC mechanism adopted the probabilistic factor obtained as a change factor between sender and receiver in synchronized manner. Sender-Receiver depicts the probabilistic change during an overload condition. R. kusching [10] illustrates that Multiplicative decrease step of AIMD algorithm reduces the receiving window (and the corresponding throughput) in case of the packet loss drastically, before the Additive increase step is initiated and tries to increase the window again. This can lead to remarkable variation of the throughput in networks with large RTTs. 3. AIPC MECHANISM 3.1 Problem Statment The goal of any overload control scheme is to reduce the load on engaged resources. Reducing the load has their costs in terms of CPU and Memory Utilization as well.

Figure 3 3.2 Proposed Mechanism The mechanism would synchronize both the sender and the receiver. Mechanism focus on both, reducing the incoming traffic at receiver end by either dropping or rejecting the traffic, based on a Probabilistic factor. While at the sender end, the sender would adjust its transmission strategies in accordance with the Receivers capacity. Receiver would increase the rate of transmission until the notice of overload occurrence and would decrease it substantially as soon as overload is noticed. In this way, both the sender and the receiver share their status to get synchronized and decrease the rate of rejection which will surely enhance the CPU utilization and corresponding Proxy Throughput. A SIP Server is said to be overloaded if atleast one of its resources is having a value more than a specified limit. In our mechanism, we set this limit as RLOW. It is a point beyond which a server starts overloading to some extent. And beyond RUP (upper limit), a SIP Server is said to be overloaded. Above RUP, the system is considered as Overloaded and it cannot handle any more requests and it starts rejecting the entire request until the Rate of Transmission falls between the RLOW and RUP. Reducing the load on the SIP proxy can be realized by either dropping incoming requests or rejecting them, e.g., sending back a 5xx reply. It is suggested in [4] that dropping incoming requests, consumes slightly less CPU at the SIP proxy than rejecting them. In order to reduce the possibility of an overload situation at the receiver side, the senders of the SIP traffic should adapt their transmission rates to the capabilities of the receivers. That is, if a SIP proxy that is currently sending traffic to another proxy notices that the receiving proxy is overloaded; the sending proxy should reduce its transmission rate so as to avoid overloading the receiving one.

131

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME

In order to avoid the sudden changes , we should sh take the average of Probability ty of rejection AIPC combines linear growth of the transmission rate with the Probab Probabilistic ilistic change during an overload condition. 3.3 Equations At Receiver Side AIPC defines two threshold points (for CPU and memory): lower (RLOW) and Upper Threshold (RUP). AIPC work in a way that the number of rejection during the overload condition is minimized. Once the lower threshold is exceeded, the AIPC starts reducing the load on the SIP server by the Probability of Rejection (PoR). This can be illustrated by rejecting the incoming requests on SIP with PoR PoR = 0 {RTRANS < RLOW} (1)

ll incoming requests coming from SIP Server is rejected as the Upper Threshold value is exceeded. This threshold is set to the amount of resources required to handle the requests in some worst case scenarios. Engineered traffic [4] is the amount of requests a SIP server is expected to receive and process simultaneously under normal operational conditions i.e. during DoS attacks or Flash crowd scenarios. PoR = 1 {RTRANS >= RUP} (2)

There will be a probabilistic change size of receiving window when the rate of receiving incoming requests lies between the Upper and Lower thresholds PoR = RTRANS >= RLOW} (3)

Parameter obtained in eq. (3) is the Probability of rejection calculated at fixed time intervals (say T) where RTRANS is the load status on SIP Server [3]. . In order to avoid sudden change and to obtain a smooth graph graph, , Average of PoR is taken in eq. (3) over the time. When : o PoRAVG5   system is not considered as Overload and there will be no dropping or rejection of incoming request is initiated. o 1 PoR 0.05, SIP Sever is considered as Overloaded. Counteractive measures are required to Sop is from being overloaded. Hence, the incoming successful INVITE messages are rejected with the parameter used in eq. (3).
132

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME

o PoR = 1, SIP Server is considered as complete overloaded and no incoming request is entertained viz. requests are rejected.
At Sender Side Sender side will use same parameter used on receiver side for reducing the rate of sending requests. AIPC enables SIP Server to estimates the overload status at its neighboring servers and adopt the change in transmission accordingly AIPC mechanism allows a faster reaction to a substantial overload condition and careful preventive reaction during the under load phases.

Figure 4 I=

At starting or under normal condition, when no overload status is received and no retransmission occurs, the sender adjusts its sending rate in an increasing manner. It follows additive increase behavior probing to usable bandwidth until the loss occurs. AIPC increases the sending by a fixed amount every round trip time. RTRANS +1 = RTRANS + { = Linear increase} (4)

Upon receiving a Overload Status (i.e. 5xx reply) AIPC uses Probabilistic parameter used in eq. (3) for reducing the rate of transmission. It is observed that overload status is received when the transmission rate exceeds the Lower threshold value. The sender will adjust its rate of transmission accordingly. When : o RTRANS RLOW , corresponding value of I lies between 0.5 to 0.9 and the rate of transmission is illustrated as RTRANS + 1 = RTRANS (1 I) (5)

The transmission rate will be adjusted in the manner of PoR at the receiver side. o RTRANS RUP, corresponding value of I will be 1 and the receiver side is regarded as complete or severely overloaded. The rate of transmission will be illustrated as RTRANS + 1 = RTRANS x I (6)

Note that the working of the equation (5) and (6) is somewhat similar. The blocking probability is lower when the transmission rate lies between lower and upper bound while it is max during the complete or severe overload condition.
133

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME 3.4 AIPC Constraints The overloaded server sends explicit congestion information to the proxy or neighboring server, the sender side (receiving this information) needs to entirely adjust its transmission rate accordingly. The complication lies here not in the rate adjustment but in determining the appropriate overload information at the overloaded server. Hence, in our approach, we will restrict the analysis to the conditions in which the overloaded servers send only implicit congestion information, e.g., rejecting or dropping traffic. These mechanisms are already part of the SIP specifications and do not require any additional logic at the receiving SIP proxies server. We assume the overload notification purely based on closed loop feedback: Detection, Signaling and Reaction. Detection phase will monitors the buffer utilization at Overload point and collects data. Signaling phase will generate proper message response (5xx) and gives feedback. The Reaction phase will refine the changes in the sending rate according to the receiver failure message.

Figure 5 Send routines should be non-blocking (asynchronous) whereas the receive routines can be blocking or non-blocking. Actions are taken on the sending and receiving end through the message response buffer. The value of probabilistic factor can be negotiated between severs at service level, for adjusting its sending rate at sender side, and for decreasing its receiver window at receiver side. Since data and signal take separate paths in SIP, hence, RTP stream does flow through the SIP server and will not represent any load for it. [9] Do not confuse imply and infer. 3.5 AIPC Analysis Tools For evaluation of our mechanism, we have used following tools for conducting the experiment: 1. Asterisk Server [14]: It is a complete PBX in software. Its runs on various platforms viz. Linux, windows, MAC OS etc. It supports three way calling, caller ID services, ADS1, IAX, SIP, H.32x, MACP and SSCP. 2. Star Trinity SIP tester [16]: It is a VoIP load testing tool which enables you to test VoIP network, SIP Software and hardware. It can simulate thousands of incoming and outgoing SIP calls with RTP streams. It can also analyze call and real time reports.
134

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME 3. SIPp tool [15]: SIPp is a free Open Source test tool / traffic generator for the SIP protocol. Features include dynamic display of statistics about running tests (call rate, round trip delay, and message statistics) and dynamically adjustable call rates. 4. Average CPUcylce [13]: It is an open source tool used to analyze the CPU usage for specific program and to find the total average CPU usage of a program for its entire uptime. 4. EXPERIMENTAL TEST BED In this section, we describe our experimental setup used for the performance analysis of AIPC mechanism under several load conditions. The test setup consists of sender and a receiver emulated using a SIP tester. Major parts of the test setup are: 4.1 SIP Server ASTERISK is used as a SIP server. It is an open source PBX machine in software. 4.2 Evaluation Machine To analyze the CPU utilization, we have used AVERAGE CPUcycles on Linux console. This is an open source tool used for measuring the CPU usage for specific program and to find the total average CPU usage of program for its entire uptime. 4.3 Hardware configuration The experiments are done with two systems in computer lab at BBD University, having following configurations. The machine acting as a Server is Intel Core 2 Duo 2.0 GHz processors with 3GB ram and 160 GB disk drive.

Figure 6 The machine hosting UAS are Intel Pentium4 1.80 GHz processor with 1GB ram and 80 Gb disk drive. Both the machines run Ubuntu OS. 5. PERFORMANCE EVALUATION For analyzing the scenario to an extent, SIP requests (INVITE) are sent to a proxy server. Successful INVITE requests are followed by another two requests viz. ACK & BYE. Rejecting INVITE requests, thereby, will save the resources required for processing the INVITE request and corresponding in-dialog request as well. The goal of our experiment is to evaluate the ability of Sip Server to handle the number of simultaneous requests during an overload condition. We evaluated the performance of AIPC during several scenarios.
135

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME 5.1 Assumption and Simulation Due to the limitation of the traffic generator tool i.e. its simple and single threaded architecture design, which prevents it from using the multiple cores at a time. Thus, to increase the call capacity, it is required to run the processes of SIPp on multiple machines.
25500 25000 24500 24000 23500 23000 22500 22000 21500 21000 20500 20000
21000 21500 22000 22500 23000 23500 24000 24500 25000

Sender

Receiver

Figure 7 Fig. 7 illustrates the message transfer between sender and the receiver when there is no attack or overload situation [2] During the simulation, we observed that a single SIPp process on a machine can generate 250 simultaneous requests. Hence we adopted four machines to generate 1000 simultaneous requests. The upper threshold beyond which the server gets overloaded is 1000. Ultimately the lower threshold is assumed to be 500 simultaneous requests. Since the media stream and signaling follow separate path in SIP, hence on the load on media stream will not affect the signaling stream. For evaluating the blocking probability, we used the Star Trinity SIP tester. The Simulation includes both single and load variance approach. Since AIPC aims at reducing the number of rejections during an overload condition according to the capability of the server to handle the simultaneous request.

Figure 8 (Source Star Trinity SIP Tester [16]) 5.2 Result For testing the performance of AIPC, the test cases are implemented on sender and receiver separately. During no overload condition, there will no probability of rejection. At Receiver Side The AIPC will starts as the number of incoming request exceeds the Lower threshold. Fig. 9 and 10 illustrates the affect of Probability of rejection on number of incoming requests. There is slight increase in the projection of rejection with the increase in the incoming request. Fig. 11 illustrates the percentage reduction in the number of requests with the probability of rejection with variable difference of 0.1. The slope in the figure represents the variance in the reduction of incoming requests with the probability of rejection.
136

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME At Sender Side Sender side will reduce the rate of transmission or simply the number of request sent to the overloaded
No. of Incoming Requests

1200 1000 800 600 400 200 0

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Probabilit y of Rejection Incoming Requets Rejected Requests

Probability of Rejection

Figure 9
Probability of Rejection Incoming Requets Rejected Requests

800 750 1000 700 650 600 720 855 550 595 500 480 280 375 195 120 55 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

850

900

950

Figure 10
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 0 0.10.20.30.40.50.60.70.80.9 0.1 1
Probability of Rejection

No. of Incoming Requests

Server Overloaded Rejected Requests Probability of Rejection

Figure 11 server as the Lower threshold is exceeded. The transmission rate is thus adjusted in accordance with the table 1. No request will be entertained beyond the upper threshold. Table1 represent the effect of probabilistic factor I on the outgoing request.
137

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME For smooth working of the AIPC mechanism, the triggering policies are based on the response messages i.e. the AIPC is revoked on sender side till the overload response is received on the sender side. It will automatically start increasing the rate of transmission linearly thereafter. Fig. 12 illustrates the effect of AIPC mechanism on the rate of transmission at sender side. It clear stated from the figure that the sending rate is inversely proportional to the probabilistic factor. Only the initials requests i.e. INVITE messages are dropped by the AIPC mechanism at the sender side. This will not only reduce the load on the overloaded server but also reduce the number of resources required to process theses requests. It is because of the fact that a successful INVITE message is followed by two more consecutive in-dialog messages viz. ACK and BYE.
1200
No. of Incoming Requests
Probabilit y of Rejection Incoming Requets

1000 800 600 400 200 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Probability of Rejection

Rejected Requests

Request Processed

Figure 12 5.3 Tables The table represents the effect of PoR on the outgoing request at sender side. Table 1 Outgoing Requests 500 550 600 650 700 750 800 850 900 950 1000

Prob. Of Rejection 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Rejected Requests 0 55 120 195 280 375 480 595 720 855 1000

138

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME 6. CONCLUSION In our findings , we observed that the dropping the INVITE requests at sender side during an overload condition , not only save the resources required to handle the requests but also reduces the extra load on the Server as well. During an interoperability event, we measured the performance of our server using a professional performance measurement tool and our server was able to fully saturate the tool. We thus, conclude that: Successful INVITE requests are followed by another two requests viz. ACK & BYE. Sender drops the initial request while the receiver (Server here) reject the active sessions. Finally, our simulation states that unresponsive active sessions can cause overload. AIPC rejects these active sessions during overload condition. Fig. 13 illustrates the performance comparison of AIPC mechanism with that of AIMD mechanism. Our curve analysis shows that AIPC mechanism performs better during the overload condition. The analysis is based on comparison between the previous and current simulation along with the mathematical model.
2000 1500 1000 500 0 1 2 3 4 5 6 7 8 9 10 11
Time (ms)
AIPC Mecha nism AIMD Mecha nism

No. of requests processed

Figure 13 FUTURE WORK Our future can extend to analyze the working of AIPC mechanism in various types of attacks. Also, enhancement tuning can also be performed in order to obtain customized result. This can be done on the basis of complexity analysis. REFERENCES [1] Italo Dacosta, Vijay Balasubramaniyan, IEEE, Mustaque Ahamad & Patrick Traynor, Member, IEEE Improving Authentication Performance of Distributed SIP Proxies, IEEE Transactions On Parallel And Distributed Systems, Vol. 22, Issue: 11, pages: 18041812, November 2011 Bansal, A. , Kulkarni, P. ; Pais, A.R. Effectiveness of SIP Messages on SIP Server, 2013 IEEE Conference Information & Communication Technologies (ICT), pages: 616-621. Dorgham, John Protecting VoIP Services against DoS using Overload Control, International Conference on Computer Communications and Networks , copenhegen, october, 2008.
139

[2] [3]

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 - 6375(Online), Volume 5, Issue 1, January (2014), IAEME [4] Dorgham Sisalem, John Floroiu VoIP Overload, a Senders Burden ,62-69 , International Conference on Computer Communications and Networks (CCN-10), Orlando, USA, July 12-14, 2010 M. Ohta, Simulation study of sip signaling in an overload condition. In Communications, Internet, and Information Technology, M. H. Hamza, Ed. IASTED/ACTA Press, 2004, pp. 321326 Book on SIP Security, Dorgham Sisalem, John Floroiu, Ulrich Abend, Henning Schulzrinne , Wiley Publications 2009 Yunhong Gu, Xinwei Hong, and Robert L. Grossman, An Analysis of AIMD Algorithm with Decreasing Increases, National Science Foundation S. Poretsky , V. Gurbani, C. Davids , Terminology for benchmarking Session initiation Protocol (SIP) Networking Devices, Dorgham Sisalem, John Floroiu, Ulrich Abend, Henning Schulzrinne , Wiley Publications 2009 Miroslav Voznak and Jan Rozhon, SIP End to End Performance Metrics, International Journal Of Mathematics And Computers In Simulation . 2012 Robert Kuschnig, Ingo Kofler , hermann Hellwagner Improving Internet video streaming performance by parallel TCP-based request-response Streams In the proceedings of 7th IEEE conference on Consumer Communications and Networking Conference (CCNC10), 2010, pages:200-2004. .R.N. Manda, R.A. Auguste Proposed mathematical model for a SIP call, In the proceedings of International Conference on Multimedia Computing and Systems (ICMCS), pages: 41-45, 10-12 May, 2012 Martin Rohricht, Roland Bless Advanced Quality-of-Service signalling for the Session initiation protocol (SIP) In the Proceedings of first IEEE ICC 2012 workshop on Telecommunications: From research to Standards, Ottawa, Canada, June 2012. http://www.boray.se/software/averagecpu/ http://www.asteriskwin32.com/ http://sipp.sourceforge.net/ http://startrinity.com/VoIP/SipTester/SipTester.aspx P.Vigneshwaran, Dr. R. Dhanasekaran, A Novel Protocol to Improve TCP Performance Proposal, International Journal of Computer Engineering & Technology (IJCET), Volume 3, Issue 2, 2012, pp. 372 - 377, ISSN Print: 0976 6367, ISSN Online: 0976 6375. Sonia, Satinder Pal, An Effective Approach to Contention Based Bandwidth Request Mechanism in Wimax Networks, International Journal of Computer Engineering & Technology (IJCET), Volume 3, Issue 2, 2012, pp. 603 - 620, ISSN Print: 0976 6367, ISSN Online: 0976 6375.

[5]

[6] [7] [8]

[9] [10]

[11]

[12]

[13] [14] [15] [16] [17]

[18]

140