Project Topics
Get Complete Project Material File(s) Now! »
Literature Review
VoIP Protocol Suite
VoIP stands for Voice over Internet Protocol and it facilitates voice/video communication between two or more participants over Internet Protocol(IP). VoIP as a technology is not represented by a single protocol or entity, a number of protocols are bundled together to form an effective architecture for VoIP-based communication. There are currently two protocol stacks in use for VoIP, IETF recommended SIP and ITU-T recommended H.323. SIP and H.323 are application layer signaling mechanisms used in each case for call establishment and control. As depicted in Figure 1, SIP is used together with SDP (Session Description protocol) for call control mechanism, H.323 has three protocols for this mechanism represented by H.245 for Call Control,H.225 for Call Signaling and RAS(Registration, Admission, and Status)[36]. A typical transport layer protocol is assisted with Real-time Transport Protocol (RTP) [33] to accurately transport digitally coded data, being coded by Coders/DeCoders (CODECS)). Real-time Control Protocol(RTCP) is used in conjunction with RTP for receiver feedback and control, and to provide QoS based on quality of data distribution[33].
Audio and Video Encoding/Decoding
Due to the analog nature of audio and video signals, they cannot be directly transferred on a data network which is purely digitized in nature. So, these signals need to be encoded into a digital form using mathematical models called Coders/DeCoders (CODECS). These CODECS are used to encode the analog signals into a digital format on the sending side, and then decode them back into analog format on receiving side [14]. Among the most commonly used CODECS are G.711, G.726, G.723.1, G729, and Speex [15][29].
Call Set-up Maintenance and Tear-down
Contrary to Signaling System 7 (SS7) [30] used in PSTN for call setup, there are two main protocols used in VoIP for signaling, namely H.323 [31] and Session Initiation Protocol (SIP) [8]. H.323 is an ITU-T recommended protocol signaling protocol, used for voice/video communication over PSTN, ATM and ISDN. H.323 provides better interoperability with legacy systems as compared to SIP. On the other hand, IETF recommended SIP is a new application-layer protocol for session establishment, maintenance and termination among two or more participants. SIP is an emerging protocol which provides end-to-end signaling for VoIP communication in data networks. It is a simple text-based protocol like HTTP and SMTP with readable SIP exchange messages. Due to the growing use of SIP as a signaling protocol in VoIP communication, H.323 is being deprecated and replaced gradually by SIP [32]. A set of protocols bundle together to form a protocol stack for SIP and H.323, as illustrated in Figure 1. SIP performance for session establishment is the major research area in this document. Section 2.2 gives detailed information about SIP transactions.
Media Transport
Once the session is established using the signaling protocol, the media (audio, video or other media streams) is ready to be exchanged between parties. In order to transfer real-time application data over Internet, it is not suitable to use a common stream-oriented protocol such as TCP. TCP is optimized for a reliable transfer of bulk data and cannot handle real-time traffic. In real-time scenario using TCP, if there is a packet loss or reordering in the network, the delivery to the recipient will be delayed until the gap is filled (which may not be acceptable in real-time communication). For this reason, UDP (which is rather unreliable and unordered datagram transport service) is widely used as transport layer protocol in VoIP [34].
In order to provide reliability for real-time traffic, UPD datagrams are further encapsulated using Real-time Transport Protocol (RTP). RTP header contains a sequence number and timestamp to correctly reassemble the media stream at the receiving end. RTP is an unreliable and provides no mechanism for retransmission; as a result the received media stream contains gaps or glitches. RTP uses error-concealment and reordering mechanisms to deal with these gaps in media. It maintains a jitter buffer for incoming media at the receiving end to avoid the glitches imposed by reordering. But this buffer also imposes latency, so its size should be chosen carefully [34]. By providing the complex mechanisms of error concealment and jitter buffer management, RTP helps to provide better Quality of Experience(QoE).
Gateway Control
In VoIP systems, the interconnection between packet-switched (Internet) and circuit-switched (PSTN) networks is established in the form of VoIP media gateways. A media gateway provides conversion between audio signals carried on telephone circuits and data traffic carried over the IP networks. IETF has specified Media Gateway Control Protocol (MGCP) [35] for controlling the media gateways between Internet and PSTNs. Media gateways can be of many types e-g. a trunking gateway interfaces between a telephone network and a VoIP network, a residential gateway provides an analog RJ-45 interface to a VoIP network, a business gateway provides a soft PBX interface to a VoIP network. A list of different types of media gateways can be found in [35].
Session Initiation Protocol (SIP)
SIP is the IETF recommended protocol for session management in real-time interactive applications. While the SIP provides control signaling for call set-up, it cannot provide exchange of other information such as VoIP client software and version, CODECs supported by the participants etc. In order to provide exchange of these parameters, Session Description Protocol (SDP)[8] is used together with SIP for multimedia information exchange.
SIP is a text-based application-layer protocol and works like HTTP request/response model. User initiates a request to a SIP server, which invokes a method and a response on server. The users are identified with Uniform Resource Identifier (URI), which uniquely identifies a SIP user on a VoIP service provider domain. A SIP URI address is similar to e-mail address e-g. sip:user@domain.com. There are a number of SIP exchange messages defined in RFC 3261 [8] and elaborated in Figure 2.
User Registration
User registration is the process by which a VoIP User Agent (UA), which is typically VoIP client software, sends a registration request to VoIP server domain in the form of SIP REGISTER message. The server registers the user and stores the entry in database. On successful registration, the server sends a 200 OK message in response (indicated by top 2 arrows in Figure 2).
Call Setup and termination
A UA initiates call setup by sending INVITE message containing the target UA username and SIP proxy server IP address. If the target UA is many hops away, INVITE may be routed through a number of proxy servers until it reaches the final destination. Destination UA sends a 100 TRYING and 180 RINGING message, meanwhile it bundles the multimedia support information in SDP header and sends it back to source UA in 200 OK with SDP message. The source UA checks the SDP parameters and acknowledges it by sending ACK message. Once the ACK is received by destination UA, the session is established and voice and/or video session is initiated by RTP. Once the call is over, A BYE message can be initiated by either of the participants.
SIP is the protocol of choice in VoIP industry due to its flexibility, simplicity and independence of underlying protocol [15], and has been under scrutiny for performance during the last decade [18]. In this project we develop the QoS benchmarking module for SIP user registration and sessions creation, in order to perform SIP performance testing. The results of this testing will be used in the design and development of multicore VoIP client and server application.
Open Source SIP Servers
As explained in the previous section, SIP follows a client/server model of communication. On client side, user applications called softphones are used as SIP clients e-g. X-Lite, Ekiga, Empathy etc can be used as example. However, in this thesis we use our own modules instead of softphones for SIP traffic generation and QoS analysis as client. On server side, there are a number of open source implementations of SIP but two of them have gained world-wide acceptance and growth: OpenSIPS [6] and Asterisk [7]. Following is a brief discretion of both servers.
Asterisk
Asterisk is a well-known and open source IP PBX system which provides all the features offered by a classic PBX system such as making simple telephone calls, call transferring, voice mail, conference calling and voice menu etc. In addition to these features, more advance features can be created and integrated by defining new Asterisk dial plan scripts. Asterisk is black-box VoIP solution which bundles all the necessary VoIP protocols including SIP, MGCP, H.323, IAX etc., and it is supported on a variety of operating systems including OpenBSD, MAC OS, Free BSD and Microsoft Windows. Inter-Asterisk Exchange(IAX) protocol provides truncking of calls among multiple Asterisk PBX systems. Asterisk can be used as soft PBX system in homes, offices, call centers, and by VoIP service providers.
OpenSIPS
OpenSIPS is a mature implementation of SIP, and it is basically designed for a comprehensive and scalable implementation of call signaling only. OpenSIPS is an open source SIP server and its major functions include high performance call routing and proxy services, with a capability to handle more than a thousand SIP calls at a time. It does not provide built-in PBX system, so it cannot be used as a stand-alone VoIP system. However, it can be used in combination with Asterisk to a soft PBX system and interconnection to PSTN.
OpenSIPS as a SIP server provides high performance features including: NAT traversal, load balancing of SIP users, SIP to SMS gateway, SIP back-to-back User Agent (B2BUA), registrar, redirector, router etc. For a complete set of features please refer to [6]. Due to these features OpenSIPS is a SIP server of choice for VoIP service providers. Since OpenSIPS is purely a signaling protocol designed to handle and route a large number of SIP users, we have selected it as platform for experiments to test QoS for SIP signaling.
Quality of Service (QoS)
QoS may be defined in different ways in telecommunication. From the Internet service provider perspective, it can be traffic engineering to load balance the internet traffic. It can be quality of experience (QoE) for a VoIP user where the user evaluates the voice or video quality. In VoIP communication, better QoE depends on the QoS provided by both control and data planes. Section 2.1.3 above mentions how RTP provides better QoE for the voice/video data, but QoE does not entirely depend on jitter or packet loss in media. Call set-up time is another important factor in the control plan which can affect QoE and is provide by SIP signaling or call set-up mechanism. This concept has emerged as Quality of Signaling (QoSg) as a new term in [20] and focuses on QoS of different parameters during call set-up process of SIP protocol, and a separate IETF draft has been evaluated only for SIP performance metrics in RFC 6076.
The scientific work in this thesis focuses on QoSg for the SIP server. The main issues are processing delay on the server, and the number of lost SIP sessions which is further based on failing registrations and packet loss. The scope is limited only to server processing since our goal is to evaluate the performance bottlenecks in existing open source servers and to investigate how a multicore SIP server can alleviate these bottlenecks. The actual design or implementation of a multicore SIP server is beyond the scope of this thesis, however, the results can be used in the design of a multicore SIP server.
Requirement Specification
As discussed in section 1.2 Problem Statement, the overall purpose development work is this thesis is to generate the SIP signaling traffic for user registration and sessions, and a results presentation module for analysis of the signaling traffic. Section 1.2 was following by a list of Objectives to be achieved during and after development process. This section further elaborates those objectives to form a set of requirement specifications in the following sub-sections.
Sending and receiving data
The first requirement for developing SQgen is to be able to send and receive TCP and UDP packets. Although UDP is the major transport protocol used in VoIP, creating TCP traffic is also important and may be used in future for comparative analysis with UDP traffic for VoIP signaling .
Controlling the payload
Once the basic functionality is established for UDP and TCP, SQgen should be able to manipulate the payload according to experiment requirements. In UDP/TCP mode, basic experiment information including timestamp, packet number, test number, security enabled etc. can be loaded into payload at sender side and extracted at receiver side for statistical analysis of packet loss and communication delay. This analysis can be done for testing a typical network set-up before running tests for SIP or other application traffic.
Support for IPv6
SQgen should be able to generate UDP/TCP traffic over both IPv4 and IPv6.
Adding Application Level Security
SQgen should be able encrypting/decrypting data with DES encryption algorithm. This feature is needed for RTT (Round Trip Time) calculation with or without security overhead. Due to the limitation of time and project scope only one cipher is being implemented in SQgen, more ciphers can be integrated in SQgen in future. OpenSSL is an open source community for Implementation of SSL(Secure Socket Layer)/TLS(Transport Layer Security) and provides source code for a number ciphers.
Emulation of a large number of SIP users for Stress Testing
A separate module should be designed and implemented to emulate a large number of SIP users to test the performance of OpenSIPS server. Using this module we should be able to achieve the following tasks:
User Registration
To be able to perform stress testing, a large number of SIP users must be registered on a live OpenSIPS server.
Session Establishment
Once the users are registered on the server, SIP sessions should be generated for the registered users using the sender and receiver of SQgen.
Modular Design for Multicore
The SQgen benchmark application should be designed and coded in independent modules. Modularity is necessary to fully utilize the capacity of a many-core platform in future, where every module can be moved to a separate processing core(e-g.SIP registration, INIVTE, session description etc. to be processed on separate cores). Multicore or parallel programming is out of scope of this master thesis; however, the modular design of SQ can be utilized in future for a fully multicore application.
In the next section, a number of stat of the art traffic generators are reviewed, to find a suitable application that can fulfill the above mentioned requirements.
State of the art IP Traffic Generators
pktgen the Linux Packet Generator
Pktgen is an in–kernal Linux based traffic generator which is known as the best tool to control the resources of the NIC and produce maximum performance results [1]. This tool is a very high performance testing tool which can generate packets at gigabit rates for high speed traffic forwarding devices such as routers and bridges. Pktgen generates only UDP traffic and sends packets to discard port(UDP port 9). The tool has been used to test the routing performance of open source Bifrost[17] routers in communication system design (CSD) project of TSLab [4].
Not suitable:
Although it is currently the best tool to produce high speed UDP traffic, it is not designed to manipulated data from other applications. And we need to generate SIP packets in order to generate SIP sessions on a live SIP server, so we cannot use it to achieve our objectives.
Table of contents :
1. Introduction
1.1 Motivation
1.2 Problem Statement
1.3 Objectives
1.4 Contribution
1.5 Organization of Report
2. Literature Review
2.1 VoIP Protocol Suite
2.1.1 Audio and Video Encoding/Decoding
2.1.2 Call Set-up Maintenance and Tear-down
2.1.3 Media Transport
2.1.4 Gateway Control
2.2 Session Initiation Protocol (SIP)
2.2.1 User Registration
2.2.2 Call Setup and termination
2.3 Open Source SIP Servers
2.3.1 Asterisk
2.3.2 OpenSIPS
2.4 Quality of Service (QoS)
2.5 Requirement Specification
2.5.1 Sending and receiving data
2.5.2 Controlling the payload
2.5.3 Support for IPv6
2.5.4 Adding Application Level Security
2.5.5 Emulation of a large number of SIP users for Stress Testing
2.5.6 Modular Design for Multicore
2.6 State of the art IP Traffic Generators
2.6.1 pktgen the Linux Packet Generator
2.6.2 Multi-Generator (MGEN)
2.6.3 SIPp
2.6.4 Netperf
2.6.5 Harpoon: A Flow-level Traffic Generator
2.6.6 Ostinato Traffic Generator and Analyzer
2.6.7 Iperf
3. Methodology
3.1 Literature Review
3.2 Requirement Analysis
3.3 Designing and Implementation
3.4 Testing
3.5 Results Presentation
4. Design and Implementation of a customized traffic generator
4.1 Design of SQgen
4.2 SIP Traffic Generator(STG) Module
4.2.1 Sender
4.2.2 Receiver
4.3 Results Presentation Module (RPM)
4.3.1 Time-stamping
4.3.2 Packet Capturing and Parameters for Parsing
4.3.3 Pseudo Algorithm and Block Diagram
5. Experimental Set-up
5.1 Test Scenarios
5.2 System specifications
6. Experimental Evaluation
6.1 Test Cases
6.1.1 Test Cases in Scenario 1
6.1.2 Test Case Scenario 2
6.2 Results
6.2.1 Delay and Packet Loss Specification
6.2.2 REGISTER Delay Scenario 1
6.2.3 REGISTER Delay Scenario 2
6.2.4 INVITE Delay Scenario 1
6.2.5 INVITE Delay Scenario 2
6.2.6 Call Setup Delay Scenario 1
6.2.7 Call Setup Delay Scenario 2
6.2.8 Packet Loss Scenario 1 and 2
6.3 Packet Loss Analysis
6.3.1 SIP Frame Sizes
6.3.2 Ethernet Link to the Server
6.3.3 Wireless Link to Sender and Receiver
6.3.4 Wireless Background Noise
6.3.5 NIC Buffer Limitation
7 Conclusions and Future Work
7.1 Conclusions
7.2 Open Issues and Future Work
7.3 Social and Ethical Aspects
7.4 Economic and Environmental Aspects
7.5 Ecologically Sustainable Development
8 References
Appendices
Appendix 1: List of Other Traffic Generators
Appendix 2: A Sample of Wireshark Packet Summaries
Appendix 3: A Sample of Timestamps recorded for 100 SIP Sessions Experiment
