An Experimental Study to Analyze SIP Traffic over LAN
Mujahid Tabassum, Kuruvilla Mathew, Mohana Ramakrishnan and Duaa Fatima S Khan,Swinburne University of Technology(Sarawak Campus), Jalan Simpang Tiga, 93350, Kuching, Malaysia [email protected], [email protected]; [email protected],
ABSTRACT
VoIP (Voice over Internet Protocol) service has become famous now days due to their affordability and flexibility. VoIP networks use IP (Internet Protocol) phone to communicate over Internet or LAN (Local Area Network). Most IP phone use SIP (Session Initiation Protocol) for communication. The SIP (Session Initiation Protocol) was invented to help RTP (Real-Time Transport Protocol) in order to find destination IP address and port address over Internet. RTP use to transmit voice data between source and destination using their IP addresses and Port numbers. NAT (Network Address Translation) is a technique, which allows users to use multiple IP address internally for multiple devices to share one Internet connection. VoIP packets are routed over public Internet, which is not a secure platform. Sometimes data face delay problem due to network congestion. Many type of security and QoS (Quality of Service) techniques and algorithms are being designed to overcome these problems.
In this paper we have experimentally analyzed and examine the bit rate and packet rate during VoIP call process. This paper will show the registration process of SIP and delay in arrival packet due to congestion on network. We have used the WireShark, packet analyzer software to observe the SIP registration and call setup process in LAN (Local Area Network) as well as inter-packet arrival times of RTP frames in the caller to callee direction. KEYWORDS
Session Initiation Protocol (SIP), Network Address Translation (NAT), Real-time Transport Protocol (RTP), WireShark
1
INTRODUCTION
In today ear, due to transformation and integration of Information Technology, telecommunication industry has gained maximum benefits and expansion. Technology has proved its existence by
offering cheaper and flexible communication solutions to end users.
VoIP (Voice over Internet Protocol) technology has gained tremendous user interest due to their offering free and affordable International calls at local call rates. Now a days calling over IP (Internet Protocol) such as Skype, Viber, WhatsApp and etc. has become common practice for users around the world. VoIP technology received good user response across the world, which has opened a new research horizon for telecommunication industry. In most countries the VoIP services have become common and popular over traditional networks. VoIP technology offers good benefit to users as well as to ISPs (Internet Service Providers) in sense of cost saving and flexibility. Now days the telecom services providers do not need to rent leased line from third party, they can simply route/ forward the traffic over IP network on very low cost, which also provide cost benefits to end users. Furthermore, VoIP services also offers live video and multimedia benefits regardless of location barriers.
VoIP technology uses signaling protocol such as SIP to process a call and media transfer protocol such as RTP for voice transmission [1]. The VoIP services are designed to operate via Internet Protocol (IP) which means VoIP equipment need to have IP addresses to transmit and receive the data packets. Sometime this process causes problems due to certain issues, NAT being one of them, which can cause connection problem in VoIP network [2].
Communication over NAT is not an easy process. The SIP message contains IP addresses in the header as well as in the body. In case of using NAT with SIP service, the SIP headers contain information of caller and receiver, and the device translates this information to hide it from the outside network. The Session Description Protocol (SDP) information such as IP address and Port number for transmission of the media, live in the SIP body. The device translates SDP information
for allocating resources to send and receive the media. For example, if a user is behind NAT on LAN (Local Area Network) and he accesses a web site, the user machine will make a connection to a web server and requests the page, which will be returned as a connection response. The connection can be NATted and allow two way data flow. However, IP telephony has a different mechanism. The start procedure is broken into two processes such as signaling and media, which mean the "connection" to establish a call, is different from the actual audio that makes up the call. When the signally sets up the call it will say "where to send the audio" instead of saying "send it to 190.160.110" (NATted address).This does not work, because the call server needs to break the SIP specification and wait for the audio to come from the device and then send its audio back to same source, allowing the phone to make an outgoing connection for the audio first. But the SIP standard does not work this way because phone behind the NAT does not have process to expect its audio to come back to the same IP and port from it was send out [3][12].
This paper has been categorized into two sections: first section will explain about SIP protocols, call processes and the second section will shows a practical VoIP scenario transmission results over LAN. We used WireShark to analyze the SIP Ethernet packets transmission results.
2
BASIC TERMINOLOGY
2.1
SIP Terminology
Session Initiation Protocol (SIP) is a signaling communications protocol, which used for setting up, modifying and ending real-time sessions between peers over an Internet Protocol (IP) network. It uses several existing protocols such as HTTP 1.1, SDP, RTP, DNS, and DHCP etc. [4]. There are five components of SIP such as:
• User Agent (UA) – an endpoint entity divided into User Agent Client (UAC) which initiates SIP request, and User Agent Server (UAS) which contacts and responds on behalf of the user.
• Proxy Server – an intermediary entity that makes requests on behalf of other clients.
• Redirect Server – similar to the proxy server but does not pass on the request to other servers.
• Registrar – an endpoint component which accepts “register” requests and places the received information into the location service for the domain it handles.
• Location Server – used by the proxy server to gain knowledge about possible locations of the party being called.
SIP deals with two types of messages [4]:
• Requests Messages are sent from the client to the server. Methods of sending a request include “SIP Invite” which is a connection establishing request between user agents. It can initiate a call and change the call parameters like in “re-invite”; “ack” which responds for “invite”; “bye” which terminates the call and “cancel” which terminates a pending request. “SIP Register” is used by the User Agent (UA) for registration with SIP proxy. It’s used to indicate current IP address and the URLs for which it would like to receive calls.
• Responses messages are sent from server to client. The response messages are either provisional or final, in digital format such as:1xx = informational messages; 2xx = final, successful completion; 3xx = final, call forwarding.
Figure. 1. SIP Servers and Components
2.2
Nonce
A “nonce” is an arbitrary number generated for a specific use, like session authentication. Using a nonce to prevents a malicious user from performing a replay attack in order to log into a client’s system. It is normally sent in SIP control messages when repetition of a transmission is not wanted and the
response is different for each authentication session, to make a replay attack impossible.
Figure. 2. Nonce (Captured by WireShark)
2.3
Session Description Protocol (SDP)
SDP is used to describe streaming multimedia session parameters [5]. SDP includes information like the session name, purpose and session active time and bandwidth used by each session.2.4
SIP Specific Protocols
The most prominent SIP specific protocols are mentioned below [6] [7][10]:
2.4.1
G.711
The G.711 is an ITU-T standard for voice transmission over telecommunication lines, used in the modern digital telephone network. It has a sampling frequency of 8kHz, a 64kb/s bit rate, sample period 20 ms and a 160 frame size.G.711 has two versions; A-law and U-law.
2.4.2
G.711 A-law
This uses a 13-bit linear PCM as input, and then converts it to 8-bit value. This provides a more dynamic range as compared to the U-law, with better suppressed sampling artifacts.
2.4.3
G.711 µ-law
This law uses a 14-bit linear PCM as input, increases it by 32 before converting to 8-bit values. This yields an encoded channel with samples coded 0xFF in the octets.
2.4.4
G.726
This is an upgraded version of the G.711 standard, which can be used for voice transmission at 16 kb/s, 24 kb/s, 32kb/s and 40kb/s channels. Also has a sampling frequency of 8 kHz, 20 ms sample period and a frame size of 80.
2.4.5
G.729
This standard operates at 8kb/s using CS-ACELP (Conjugate-Structure Algebraic Code-Exited linear-Prediction). It compresses voice audio in 10 millisecond frames. Because of the lower bit rate, it is ideal for use in scenarios with limited bandwidths, like international VoIP service and satellite connections. It also has frame size of 10.
2.5
Comfort Noise Generation
Basically, a Comfort Noise Generator (CNG) is a program used for creation of noise during voice communication when there is a period of silence. The CNG is used in association with discontinuous transmission (DTX), which means that the transmitter is switched off during silent periods [8].
2.6
Network Address Translation
Network Address Translation (NAT) is an Internet standard, which allows a LAN to use a particular set of IP address for the internal traffic and a different set for external traffic. It provides security for the internal set of address by hiding them behind a firewall [8] [9] [11].
2.6.1
Full Cone NAT
This is the least restrictive kind of NAT, which known as one-one NAT. It allows port is permanently open and allows inbound connections from any external host [8].
Figure. 3. Full Cone NAT
2.6.2
Restricted Cone NAT
This works the same way as the Full Cone NAT works, the difference being a few IP address restrictions. The internal hosts would have to send packets to an external host before they can receive anything from the same external hosts [8].
Figure. 4. Restricted Cone NAT
2.6.3
Port Restricted Cone NAT
This works the same way as the Restricted Cone NAT works, the difference being the added restrictions on the port. The Port Restricted Cone NAT restricts connections further by only accepting connections from the IP address and port, it sent the outbound request to.
Figure. 5. Port Restricted Cone NAT
2.6.4
Symmetric NAT
This is the strictest kind of NAT, because a socket is only made available to a specific host for a specific request. Only an external host that receives a packet from an internal host can send back a packet [8].
If one home VoIP client dials the other client’s “phone number”, the resulting RTP stream will not stay entirely within the home LAN. This is because VoIP uses dynamic port numbers that are negotiated while establishing a call. The broadband home router would have to scan and translate the addresses first because of the NAT, before identifying and attempting to connect to the client within the network.
Figure. 6. Symmetric NAT
3
IMPLEMENTATION AND RESULTS
To understand and examine the SIP communication mechanism, we have implemented a simple home based scenario. In the following paper we have connected two separate PCs on a home LAN using a single' broadband home router that connects home LAN to the Internet connection. The home router implements NAT to share a single public IP address between all PCs on the home LAN. Both home PCs are running with VoIP clients. Each VoIP client registers (using SIP) with an external SIP-based VoIP Service Provider and each VoIP client have its own phone number. A trace file was created by monitoring packets at a certain point between a SIP Client and a SIP Proxy. A number of phone calls were made while capturing packets. Through WireShark, the SIP registration process and SIP session set-up were examined. The two-way RTP media streams generated during the calls were examined, as cumulative distribution functions, to view the distribution of inter-packet arrival times of RTP frames in the caller to callee direction for each call and vice versa.Figure. 7. SIP Scenario
The trace file was created by capturing the packets at a certain point between a SIP Client and a SIP Proxy. The IP addresses of the two are as follows: 1. IP address of SIP Client: 136.186.229.95 2. IP address of SIP Proxy: 210.50.193.198
This was confirmed by the flow graph obtained from WireShark, shown in figure 8.
From the figure it can be observed that the Requests i.e. messages sent from Client to server are generated by 136.186.229.95 whereas the Responses i.e. the messages sent from sent from the server to the client are generated by 210.50.193.198.
3.1
Time-To-Live (TTL)
TTL is a value in an Internet Protocol (IP) packet that specifies the number of hops that a packet is permitted to travel before being discarded by a router. In the provided trace file, if the default TTL is assumed to be 64 hops, then the TTL value from the client to the device running WireShark is 64 hops and the TTL value from the proxy to the device running WireShark is 51 hops evident from the following figures:
Figure. 9. Value from client.0: TTL
Figure. 10. TTL value from Proxy
Hence,
No. of hops from client = 64 - 64 = 0 Hops No. of hops from proxy = 64 -51 = 13 Hops
3.2
MAC Address
The following figure shows the Ethernet addresses during the communication between the client and server, as it can be observed that the source MAC address is 00:08:74:df:70:3e which is the physical address of the client and the destination address is 00:00:0c:07:ac:e5 which is to all HSRP ( Hot
Standby Router Protocol ) routers. This destination MAC address represents the virtual address of all the HSRP routers in the WAN.
Figure. 11. Ethernet address from client to server
The following figure shows the Ethernet addresses during the communication between the servers to the client. It can be observed that when the HSRP router replies to client’s request, it uses its own MAC address i.e. 00:14:f1:02:78:00, instead of the destination address used in the above figure and also uses the client MAC address as the destination.
Figure. 12. Ethernet address from HSRP router to client
3.3
No. of Calls
There were two (2) phone calls captured in the tracefile which can be verified by using the “VoIP call” option of WireShark as shown below:
Figure. 13. No. of calls
The Number of SIP Packets captured was 41 Packets, which can be verified by the SIP statistics as shown in the figure 14.
It consisted of SIP packets (responses as well as requests) as shown on figure 15.
Figure. 15. Types of SIP Packets
Figure. 16. No. of RTP Packets for 4 streams
The number of RTP packets captured can be calculated by adding the RTP packets for all the 4 streams as shown in figure 16.
Total no. of RTP packets = 4186 + 5506 + 4134 + 5141 = 18967 packets
3.4
Direction, duration of call
The details of both the calls can be observed from Figure 13.
3.4.1
First Call
“Mujahid” with SIP ID of
<[email protected]>made a call to “FathimahSaiqeeb” with SIP ID <[email protected]>. The duration of the call can be calculated by subtracting the start and stop time i.e.
Duration of call = Stop Time – Start Time= 115.398481 – 14.991120 = 100.407361 seconds i.e. Mujahid was calling Fathimah.
3.4.2
Second Call
“Fathimah Saiqeeb” with SIP ID of <[email protected]> made a call to client with SIP ID <[email protected]>. The duration of the call is given by:
Duration of call = Stop Time – Start Time= 279.332307 – 168.326766 = 111.005541 seconds. A SIP registration process consists of the following steps:
Figure. 17. SIP Registration Process
“401 Unauthorized” message is generated by the SIP server in order to get authentication from the client which was also seen in the provided trace file, in which client’s initial attempt to register was rejected with a “401 Unauthorized” message by the SIP server. This can be confirmed by the flow graph:
Figure. 18. Registration process for the trace file
A second registration message was sent by the client after the failure of the first registration attempt failed, with the following authorization information:
Figure. 19. Nonce Value
A nonce value of 362bafac was provided by the SIP server in response to the client’s initial attempts to register.
The very last REGISTER message in the provided trace file had an 'Expires' value of zero as the registration was being cancelled.
Figure. 20. SIP INVITE Message & 1st RTU media stream
The flow graph shows the time between the initial INVITE message and the first RTP media stream and the time spent while waiting for the call to be picked.
Time between the initial IVITE and the first RTP media stream of the first phone call was
= 31.573882 – 14.991120 =16.582762 sec
The Time Spent while waiting for the call to be picked up = 31.573882 – 15.007001 (100 Trying message) = 16.566881sec
The distribution of inter-packet arrival times of RTP frames in from caller to the one being called is shown in the graphs (figure 21, figure 22, figure 23, figure 24) for each of the call
Figure. 21. Inter-packet Arrival Time Graph for First Call
Figure. 22. Inter-packet Arrival Time Graph for Second Call
Figure. 23. Inter-Packet Arrival Time Graph For First Call
It can be observed that the inter-packet arrival time for the first call is higher as compared to the second call. The arrival times of packets for the first call keeps varying with time which could be due to network congestion, improper queuing, or configuration errors on the intermediary devices on the network.
Figure. 24. Inter-Packet Arrival Time Graph For Second Call
The distribution does not vary greatly for the first call in the reverse direction as can be observed in the first graph, which is a result of the congestion due to traffic traversing different bandwidth links. However, in the second call, the inter-packet arrival time for the reverse direction remains fairly constant throughout the call evident from the second graph, which is a result of queuing delay on the devices in the reverse direction.
As it can be concluded that as packets traversing the Internet follow different paths having different bandwidth or increased traffic which can cause the arrival times of packets to vary.
The IP-level bit rate and packet rate over time for each RTP flow in each direction was plotted using
the IO Graph in WireShark as shown in the following graph.
Figure. 25. IP-Level bit rate over time plot
Figure. 26. IP-Level packet rate over time plot
From the above graphs it can be observed that the bit rate and packet rate is at its peak value at certain periods whereas it is almost flat for the rest of the periods. It can be concluded that here were 2 calls being made, the first from ≈ 30 sec - 120 sec, with a bit rate and packet rate ≈170000 bits and 100 packets respectively and a calling time of ≈ 90 sec, whereas the second ≈170 sec - 280 sec, with a bit rate and packet rate similar to the first call and total calling time of ≈ 110 sec. It can further explained that the bit rate and packet rate was almost completely utilized during the calls. After the first call, it was left unused for some period and then the second call was made and left it unused again after it has finished.
3.5
Identification of Secret Message
The Internet Message Format (IMF) packet was used to find the secret message. IMF is the protocol used for text messages transferred over the internet.Hence in order to find the secret message first the IMF packet was searched for by the “filter” option in WireShark as shown below:
Figure. 27. Search result for IMF Packet
(WireShark)
Figure. 28. Secret Message in Line-based text data
Figure. 29. Secret Message
The IMF protocol packet was selected which is packet number 14306 as shown in the above figure. The secret message was found in the line-based test data, as shown below:
From the figure 29, the secret message is visible and states: “I want to tell you the secret message….. The message is “I forgot my cell” That is all. Fathimah”.
4
CONCLUSION
VoIP technology offer good benefits to end users but it still in early stage. VoIP used public Internet as transmission platform to transmit data which is not a secure solution. Speed and security are two main considerations of this technology. Many solutions are been introduce to accommodate these issues.
In this paper we have used WireShark packet analyzer software to understand the SIP connection setup process and evaluate the traffic parameter such as bit rate and packet rate over LAN network. We have also tried to sniff the data packet to retrieve the message inside packet header.
In future more sophistic techniques are required to improve the security and speed related issues of VoIP.
REFERNCES
[1] A. Agrawal, K. R. Prasanna Kumar & G. Athithan, “SIP/RTP session analysis and tracking for VoIP logging” published in 16th IEEE 16th IEEE International Conference on Networking (ICON 2008), New Delhi, India, December12-14, 2008. [2] Andrews & Arnold Ltd, "SIP and NAT", Retrieved
September 20, 2013, from http://aa.net.uk/kb-telecoms-sipnat.html.
[3] Juniper Networks, J series and SRX Series
Documentation and Release Notes "Understanding SIP with Network Address Translation (NAT) ", Retrieved September 20, 2013, fromhttp://www.juniper.net/techpubs/software/junos -security/junos-security96/junos-security-swconfig-security/id-60290.html.
[4] The Free Encyclopedia. Wikimedia Foundation Inc., "Session Initiation Protocol (SIP)", Retrieved
September 20, 2013, fromhttp://en.wikipedia.org/wiki/Session_Initiation_
Protocol.
[5] M. Handley & J. Jacobson (1998) "SDP: Session Description Protocol", Retrieved September 23, 2013, from www.ietf.org/rfc/rfc2327.txt .
[6] RADVISION Ltd@2001, "SIP: Protocol Overview", Retrieved September 23, 2013, fromhttp://www.radvision.com/nr/rdonlyres/51855e
82-bd7c-4d9d-aa8a-e822e3f4a81f/0/radvisionsipprotocoloverview.pdf . [7] Voip-info-org, "ITU G.711", Retrieved September
23, 2013, fromhttp://www.voip-info.org/wiki/view/ITU+G.711 .
[8] Sakhnov, Kirill & S. Boris (2010) “Method for Comfort Noise Generation and Voice Activity Detection for use in Echo Cancellation System” Prague, 2010.
[9] J. Lefort, "Understanding NAT When Setting up Lync", Premier Field Engineering, Retrieved September 23, 2013, from http://blogs.technet.com/b/mspfe/archive/2012/04/17 /understanding_2d00_nat_2d00_when_2d00_setting _2d00_up_2d00_lync_2d00_part_2d00_2_2d00_stu n_2d00_and_2d00_turn_2d00_explained.aspx . [10]WEBOPEDIA, "G.7XX" , Retrieved September 23,
2013, from http://www.webopedia.com/TERM/G/G_7xx.html . [11][4] The Free Encyclopedia. Wikimedia Foundation
Inc. , "Network Address Translation" Retrieved September 24 2013, from https://en.wikipedia.org/wiki/Network_address_tran
slation#Applications_affected_by_NAT viewed 5/10/2013
[12]A. Constantinescu, M., V. Croitoru & D. O. Cernaianu, "NAT / Firewall Traversal for SIP: Issues and Solutions ", published in Signals, Circuits and Systems, 2005. ISSCS 2005. International Symposium on Signal, Circuits & Systems, (Volume:2 ), LasI, Romania, July 14-15, 2005
