Analyzing the QoS of VoIP on SIP in Java

Transcription

1 VI International Telecommunications Symposium (ITS26), September 3-6, 26, Fortaleza-CE, Brazil Analyzing the QoS of VoIP on SIP in Java J.M. da Silva Jr. and R. D. Lins Abstract Java is a platform independent, portable, robust and distributed programming language suitable for the development of Internet applications. Performance is its strongest limitation. This paper analyses the quality of service provided by the Session Initiation Protocol (SIP) for Voice on IP implemented in Java. Delay, jitter and packet losses are tested. T Index Ter QoS, VoIP, SIP, Java, Computer Networks I. INTRODUCTION HE Public Switched Telephone Network (PSTN) exists over a century [2]. It is a billion dollar market per year. Differently from radio, television and conventional telephony that use different technologies for implementing their services, multimedia transportation through the Internet uses a common technology without taking into account the nature of the transported data[8][7]. Different protocols were developed to support different kinds of multimedia applications [7]. Amongst them one finds: the User Datagram Protocol (UDP), the Real-Time Transport Protocol (RTP), the Session Initiation Protocol (SIP), and the Session Description Protocol (SDP). The exponential growth of the Internet on the last decade increased the interest in the technology of VoIP - Voice over IP (the Internet Protocol) or, as it is also known, IPtelephony, as an alternative to conventional telephony [7]. VoIP provides real-time voice packets between two or more participants. Together with voice data control information is also sent. Voice is digitalized and compressed with a codec (encoder-decoder). The encoded voice is split into packets and transmitted through the IP network. At arrival, packets are ordered, reassembled, and decoded. The Java programming language represents a major revolution of programming paradigm for distributed applications as it split up with the client-server model, providing real distributed processing [][5]. In Java progra are first-order citizens as the answer of a query may be a program sent through the network. Java is a platform independent, portable, robust, and distributed programming language suitable for the development of Internet applications. Despite all these very desirable features, there is a serious drawback to be overcome: Java performance is slow, thus it poses a challenge of great proportions in real-time applications such as IP telephony. The target of this work is to analyze the quality of service provided by a Java implementation [6] of the Session Initiation Protocol (SIP) [8][7] in respect to quality of voice at receiver end, delay and jitter. This paper presents the result of an experimental test set involving the developed Java version of SIP on different network topologies and operating syste. II. EXPERIMENT TEST BED Figure presents the architecture of the network adopted in this study. The test bed adopted encompasses a local area network with four machines with different operating syste connected through an Ethernet Mb/s, with a hub/switch / Mb/s. The LAN is connected to a fifth machine with an Internet connection through an Internet Modem Link at 33,6 bps. Computador Win2 professional Computador 3 Linux Red Hat Computador 4 Win2 Server Computador 2 Win2 Server Switch Figure Test bed Router INTERNET Computador 5 Win2 professional Switch Six different test scenarios were defined and are presented on Table I. LAN Test Voice traffic only Mbit/s Ethernet with micros Test 2 Voice + random data traffic connected through hub/switch Ethernet /Mbit/s Test 3 Test 4 Voice + uniform and continuous data traffic Voice + data traffic at 3% of the network capacity Internet Modem Link 33.6 bps Test 5 Voice + random data traffic Test 6 Voice + uniform and continuous data traffic Table I Experiment Scenarios Router Machine times are synchronized to make easier the data capture process on packet delivery delays and jitter. SIP is not affected by this synchronization. All test scenarios made use of the SIP command sequence depicted in Figure 2. Jucimar Maia da Silva Jr. and Rafael Dueire Lins, Department of Electronic and Syste, Telecommunication Group, Center of Technology and Geosciences, Federal University of Pernambuco, Recife, Brazil, e- mails: rdl@ufpe.br. SBrT 34

2 VI International Telecommunications Symposium (ITS26), September 3-6, 26, Fortaleza-CE, Brazil 2 Kaio Anna INVITE a RINGING b OK c ACK d e Conversação (RTP/RTCP) sample is wrapped up in a RTP packet. For purposes of log file generation the RTP header was expanded with a field called DTHR_ENVIO (8bytes) to store the data and time each packet was sent. Each RTP packet becomes 8 bytes long. The SENDER computer delivers packets via IP network to the RECIEVER. The RECEIVER generates the log of each arriving packet. This log is formed with the data of the RTP header (with the time of when the packet was sent) as well as the data and time of arrival. These data are used for analysis. f BYE voz_feminina.au voz_feminina.au PCM 6bits 8KHz g OK Figure 2. SIP commands in Test scenarios... PCM 6bits 8KHz remetente t III. COLLECTING DATA OF PACKAGE LOSSES AND JITTER G.7 8bits 8KHz To measure delays, packet losses and jitter the strategy was to send a pre-recorded voice file called voz_feminina.au (Figure3), which was produced with Sound Forge 5b with format PCM 6Bits 8MHz. This is the sound format generated before encoding under m-law or A-law [9]. Figure 4 presents other properties of the file. pacote RTP G.7 8bits 8KHz Rede IP destinatário log Figure 3 Process of Test scenario A. Test Scenario Figure Voice sample voz_feminina.au In this experiment only voice was sent through the network. There was no packet loss, with perfect exchange of SIP messages. Figure 6 shows a delay in packet arrival shown by a discontinuity. The jitter obtained in this architecture is shown in Figure 7, in which one may observe that all packets arrived between and 5. This jitter may be considered small. Tempo de chegadas dos Figure 2 Properties of file voz_feminina.au Figure 4 Test scenario Time of packet arrival This file lasts 3min and 5,28s of recorded voice. The file is split into samples of 32bytes, encoded under G.7 m- Law with 8bits, 8 KHz, generating samples of 6bytes (that corresponds to 2 of voice), making a total of 9764 packets. The packets are sent as described in figure 4. Each SBrT 35

3 VI International Telecommunications Symposium (ITS26), September 3-6, 26, Fortaleza-CE, Brazil 3 qtde Figure 5 Test scenario break in the conversation. There was an increase in the jitter, as the time of arrival between packets varied as shown in Figure. This did not affect the quality of the conversation B. Experiment 2 In this test scenario a random data burst was introduced to analyze its effect on the voice quality. There was no packet loss neither of data (voice) nor signaling. Figure 8 shows an anomalous delay in packet arrival which is represented by the discontinuity in the graph. The data burst did not influence the quality of voice as the arrival delay and jitter were not significant Figure 6 Test scenario 2 Time of arrival of packets. Figure 8 Test scenario 3 Time arrival of packets. D. Test scenario Figure 9 Test scenario 3 - In this scenario the network traffic was increased of 3% through the use of tools and applicatives, simulating heavy network traffic. The delay in packet time of arrival raised and an anomalous behavior was detected (Figure2). Tempo de chegada do pacote Figure 7 Test scenario C. Test scenario 3 During this performance test there is a continuous data flux (another computer made FTP) while the voice information was sent. In this scenario there was no SIP or RTP packet loss. Again, a perceptible delay was detected during conversation as shown in Figure. This delay caused a Figure Test scenario 4 Time of arrival of packets The jitter found in this experiment was small, as may de observed in Figure3, being not sufficient to affect the quality of voice. There were no packet losses. SBrT 36

4 VI International Telecommunications Symposium (ITS26), September 3-6, 26, Fortaleza-CE, Brazil E. Test scenario 5 Figure. Test scenario This test scenario simulates an Internet link dedicated to conversation. The SENDER and RECEIVER computers are connected through a 2Mbit link though a 33.6Kbps modem. Packets reached their destination with a considerable linear delay (see Figure 4) that affected the voice quality. Besides that, the time elapsed in sending voice packets was much longer than the original voice file (3min and 5s, approximately). F. Test scenario 6 The last experiment set simulates a simultaneous conversation with continuous data transfer (file transfer under FTP). As in the last scenario, the SENDER and RECEIVER computers are connected through a 2Mbit link though a 33.6Kbps modem. The delay observed made the just over 3 minute voice traffic to last over 5 minutes, a completely unbearable delay Figure.4 Test scenario 6 - Time of arrival of packets Figure 2 Test scenario 5 - Time of arrival of packets Packets were received in bursts of units. Between them a delay of about 2 s was observed. Figure 5 presents the graph of the jitter in this scenario. Almost half of packets took longer than 3 to arrive, an unbearable delay for Internet conversation. Figure 5 Test scenario 6 The jitter observed in this experiment, is shown in Figure 7, and was also very large jumping from 3 to almost 2, varying widely in between. IV. COMPARISON BETWEEN LAN TEST SCENARIOS Figure8 shows that whenever there was no or low traffic in the network, i.e. the network is dedicated to voice data transfer, the delays found were negligible. The rise in network traffic to 7% of the network capacity as set in test scenario 4 raised the delay to twice as much as before. Despite of that, the variation in network load did not affect the quality of conversation Figure.3 Test scenario 5 - SBrT 37

5 VI International Telecommunications Symposium (ITS26), September 3-6, 26, Fortaleza-CE, Brazil 5 Experimento Experimento 2 Experimento 3 Experimento Exp 5 Exp Figure Comparison of delay of packets in test scenarios -4. Figure9 shows that all packets arrived with jitter of less than 2, thus not affecting the quality of conversation. There was no packet loss in any of the experiments. exp exp2 exp3 exp4 Figure. Comparison of packet delays between Test scenarios 5 and 6 The comparison of the jitter of the experiments presented in Figure2 shows that the values obtained are similar up to 2. This point corresponds to the peak in FTP data transfer in test scenario 6. From this point on, there is a large variation in the values obtained. Exp5 Exp6 a a 2 2 a 5 5 a a 2 Acima de 2 Figure 2 Comparison of jitter in test scenarios -4. In the four test scenarios the sequence of SIP messages was successful. There were no delays in delivery of SIP/UDP packets. Regarding packets RTP, in all experiments there were delays in some points of conversation. The delay in packets was minimum and within acceptable IP Telephony standards (3). Thus, the experiments show that the implementation of SIP in Java for VoIP is viable for LANs. V. COMPARISON BETWEEN INTERNET TEST SCENARIOS Test scenario 6 warns that communication together with data exchange yields a delay that makes the configuration unviable as it doubles in value in relation to the experiment in test scenario 5 (Figure2). This delay made conversation non-understandable as its duration moved from 3min e 5s into over 5 minutes. a a 5 5 a a 2 2 a 3 3 a a 2 2 a a 3 3 a 35 Figure.2 Comparison of jitter between Test scenarios 5 and 6 Acima de 35 In the two experiments the sequences of SIP messages were successful. There was no delay in the delivery of SIP/UDP packets. Regarding RTP packets, packet loss was minimum (only one packet in test set 5 and eleven in 6. This corroborates the fact that a packet loss of below 5% does not effect conversation. Quality of voice is affected by delay and jitter. In both experiments these factors made unviable conversation with a connection of 33.6Kbps using G.7 PCM m-law, because a 64Kbps regular flux is needed. Thus one needs to employ more sophisticated codecs such as G.729 or G.723. [][2][3][4]. Even so the experiments performed voice data exchange without packet losses. VI. CONCLUSIONS AND LINES FOR FURTHER WORK There are still several improvements to be incorporated to IP telephony in order it to compete in equal grounds with the conventional telephonic system. In 999, the IETF published the Request for Comments (RFC) 2543 that defined the Session Initiation Protocol (SIP) as the signaling model for IP telephony [7][8][]. It was developed taking scalability, re-use and interoperability into account. Forecasts made then indicated that from 24 onwards there would be a great increase in IP telephony. This rise is happening at a steady pace. There are today several dozens mature implementations of the SIP, and it is playing a key role in the development of IP telephony. SBrT 38

6 VI International Telecommunications Symposium (ITS26), September 3-6, 26, Fortaleza-CE, Brazil 6 Although Java is slow for desktop applications, this work shows that the USER AGENT SIP may be implemented in Java. This performance is reachable by code optimization and service distribution amongst classes. A great degree of difficulty was met in finding the source code of the most recent encoders as they are protected by patents. There are several lines for future work worth following: Implementing a SIP proxy; Implementing new and more advanced voice encoders (G.729, GSM, etc.)[][2][3][4] to be used in applications instead of G.7[9]; Move the application to J2EE, building a voice service via Web with several applications. To develop the adaptive algorithm presented in reference [6]; REFERENCES [] ABINADER, J.A. and LINS, R.D.; Web Services in Java, SBrT-Brasport, 26. [2] ALENCAR, M. Telefonia Digital, Editora Érica, 998. [3] FINEBERG, V, A Practical Architecture for Implementing End-to-End QoS in an IP Network, IEEE Communications Magazine, January 22. [4] HANDLEY, M.; SCHULZRINNE, H.; SCHOLLER, E.; H., ROSEMBERG, J; SIP: Session Initiation Protocol, RFC 2543, March 999. [5] JANSEN, J.; et al, Assessing Voice Quality in Packet Based Telephony, IEEE Internet Computing, June 22 [6] NOBREGA, O; An adaptive algorithm for transmission of services of VoIP, MSc thesis, UFPE, 2. [7] SCHULZRINNE, H., ROSEMBERG, J.; Internet Telephony: Architecture and Protocols an IETF Perspective, July 998. [8] SCHULZRINNE, H.; ROSEMBERG, J.; A Comparison of SIP and H.323 for Internet Telephony, Network and Operating System Support for Digital Audio and Video (NOSSDAV), Cambridge, 998. [9] SPANIAS, A., Speech Coding: A tutorial review, Proc. of IEEE, Vol 82(), Outober 994. [] VARSHNEY, U. et al; Voice over IP, CACM, January 22. [] ITU Recomendations G.722, Description of the digital test sequences for the verification of the G kbits/s SB-ADPCM 7KHz coded [2] ITU Recomendations G.726, 4, 32, 24, 6 kbits/s Adaptive Diffrencial Pulse Code Modulatin (ADPCM). [3] ITU Recomendations G.728, Coding Speech at 6kbits/s using low-delay code excited linear prediction. [4] ITU Recomendations G.728, G.723. Dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s. [5] Java Home Page, [6] Java Sound API Programmer s Guide, [7] Voice Over IP Protocols: an overview, SBrT 39