Page | 2
TABLE OF CONTENTS
Page
TABLE OF CONTENTS ........................................................................................................... 2
ABSTRACT .............................................................................................................................. 3
KEYWORDS ............................................................................................................................. 3
MOTIVATION ........................................................................................................................... 3
PREPARATION ........................................................................................................................ 3
PROJECT ARCHITECTURE ................................................................................................... 4
RESOURCES ........................................................................................................................... 4
TROUBLESHOOTS .................................................................................................................. 4
RTP CONFIGURATION .......................................................................................................... 10
SIP........................................................................................................................................... 10
SESSION DESCRICTION PROTOCOL .................................................................................. 12
REAL TIME CONTROL PROTOCOL ......................................................................................13
REGISTRATION ..................................................................................................................... 13
CALL SETUP PROCESS ........................................................................................................14
RTP ANALYSIS ...................................................................................................................... 15
TRANSMISSION DELAY ....................................................................................................... 18
QUEUING................................................................................................................................ 19
PROPAGATION DELAY ..........................................................................................................19
NODAL PROCESSING ...........................................................................................................20
CODEC BIT RATE ................................................................................................................. 26
CODEC SAMPLE SIZE ........................................................................................................... 26
MOS .........................................................................................................................................26
VOICE PAYLOAD SIZE .......................................................................................................... 26
PPS ......................................................................................................................................... 26
BANDWIDTH CALCULATION FORMULAS ........................................................................... 26
SAMPLE CALCULATION ....................................................................................................... 27
FINAL MEASUREMENT ..........................................................................................................27
REFERENCES .........................................................................................................................32

Page | 3
Abstract:
In this research we will analyze the quality of service for voice over IP (VoIP) system between
devices connected in LAN and LTE/3G network. The next generation network will be totally
depends on IP based network. Not only the voice communication but also the media streaming
even though each electronics device for our daily household services will be based on IP. So IP
telephony will become a great solution instead of ordinary radio communication system. This
technology will give a great financial benefit as well as technical revolution. So our task is to
study voice calls as well as video sessions over VoIP between LTE/3G and LAN networks.
Keywords: Packet loss, Payload, Jitter, Delay, Bandwidth.
Motivation:
VoIP means Voice over Internet Protocol. Through the Internet Protocol voice call can be
established. In this project our goal is to establish a session with the phone (hardphone or
softphone) via VoIP server to which 3G or LTE Network is interconnected. Along with voice calls
video session also has to be establish in this project.
Preparation:
VoIP is not a P2P communication. So a dedicated communication server and a VoIP gateway is
required to establish call session between two users. Off course the users must be registered to
the communication server.
Asterisk is that kind of communication framework which makes the ordinary computer to a
communication server. It is a software implementation of telephone PBX (Private Branch
Exchange). Asterisk uses SIP (Session Initiation Protocol) to establish real time multimedia
session between users.
In this project there are two IP phones, one softphone installed in a PC, three smartphones and
a PC for Asterisk server. Among the three smartphones one is which used for LTE/3G network.
A free SIM with unlimited data and maximum bandwidth is provided by the NGN lab of FH Köln.
There was no problem to register the IP Phones and softphone to the Asterisk server because
they are installed in the lab and have the same DNS & Gateway as the Asterisk server as well
as the first three bytes of the IP address is same (139.6.19.xxx). But from the outside world the
LTE/3G smartphones have the different IP addresses and the internal Firewall of the NGN lab
do not permits the unknown IPs to access its internal network.
As a solution a range of RTP ports (from 25008 - 25027) has opened in the Firewall maintaining
the rule that only those outside IP devices can access to the internal Asterisk server who have
the same IP address 139.6.xxx.xxx for the first two bytes. Because otherwise any outside
unwanted devices will try to access the lab server.
But port numbers must also be defined in the Asterisk’s RTP configuration file (rtp.conf).
Otherwise it will not accept those incoming requests.

Page | 4
But how any device will have its first two bytes of IP as 139.6.xxx.xxx. The solution is virtual
private network (VPN). VPN is a network which provides a secure and encrypted tunnel to
access the internal network from the internet. The FH Köln has dedicated IP address as
139.6.xxx.xxx of its own. So any outside device connected to the FH Köln server through the
cisco VPN software will have access to the internal network.
Project Architecture:
Here is the network architecture for the project.
Fig 1: Network architecture for the project
Resources:
1. A PC with Ubuntu OS to install open source Asterisk server.
2. A 2nd PC to install the softphone Zoiper (Ubuntu OS).
3. A webcam.
4. A headphone.
5. Two IP Phones (Grandstream GXV3140 & snom 360).
6. Three smartphones with ‘Antisip’ app as a VoIP client.
7. The server pc also have a zoiper client installed.
Troubleshoots:
If the Asterisk is not installed properly then problems will occur during work. So at first make
sure that it is installed correctly. If any error occurs during Asterisk as well as Dahdi and Libpri
installation just copy that full error message and paste that on GOOGLE. We can find the
related solutions for that error where some of them marked as ‘[SOLVED]’ which means the
issue has been solved.

Page | 5
Another important thing should be remembered during installation is that these three software
must be installed in right order i.e. DAHDI > libpri > Asterisk. This is because libpri 1.4.13 and
later source code depends on DAHDI include files. And so as Asterisk does.
After installation finishes and before start Asterisk the DAHDI must be started. Start DAHDI by
the following command:
/etc/init.d/dahdi start
Then start Asterisk and connect to the CLI.
/etc/init.d/asterisk start or
cd /etc/asterisk and then
asterisk -rvvvvv
Sometimes Asterisk may not execute any sip command. But others may work. When there is a
sip command given to the ‘CLI>’ such as ‘sip show peers’, the output may show like this:
No such command 'sip show peers'
The problem can be the chan_sip module. It may not be loaded. To check this enter the
command:
*CLI> module show like chan_sip.so
The output will be like this:
*CLI> module show like chan_sip.so
Module Description Use Count Status
chan_sip.so Session Initiation Protocol (SIP) 0 Not Running
1 modules loaded
Here, we can see the chan_sip.so module status is “Not Running”. That means it might be a
problem in the module configuration file. Go to /etc./asterisk folder and open modules.conf file.
If we had a line as follows:
noload => chan_sip.so
That would tell Asterisk to not load chan_sip.so.
If auto load is not in use, then be sure you have a load line for the module chan_sip.so to load.

Page | 6
load => chan_sip.so
Or, preload => chan_sip.so can also be used.
No audio: During voice call when microphone and the sound speaker is ok and then if no sound
cannot be heard, the probable problem can be the codec selection in the phone settings either
in the IP Phone or the Smartphone. Make sure that both phones have the same codec enabled
for the successful full duplex conversation. In our project we have enabled the PCMU (ulaw),
PCMA (alaw), gsm for the both phones. Also make sure that the sip.conf file has the line like
“allow=ulaw” and for all other audio & video codecs also.
No video: During the video call when voice is ok for both parties then video may not be ok i.e.
there may not be any video. As stated earlier this also can be codec problem. Make sure that
both phone has the same video codec enable. And also the sip.conf file allows it.
If one issues the "core show settings" command from the Asterisk CLI it will show both a "Root"
and "Current" console verbosity levels. This is because each console, core or remote has an
independent verbosity setting. For instance, if we start asterisk with the following command:
asterisk -cv
This starts Asterisk in console mode (will be the root console) with a verbose level set to "1".
Now if one issues a "core show settings" from this console's CLI the following should be
observed (note, not showing all settings):
*CLI> core show settings
PBX Core settings
-----------------
...
Root console verbosity: 1
Current console verbosity: 1
...
The verbose level ranged from 1 to 4. The command ‘asterisk -rv’ sets the level to ‘1’ or asterisk
-rvvvv sets the level to 4. This sends message of debugging output to the console via verbose
message system. No -v means the level will be ‘0’. More than 4 ‘v’ will be counts as level ‘1’ too.

Page | 7
Sip configuration file (sip.conf)
; Registering a user in sip.conf
[office-phones](!)
type=friend
; type friend means user can receive & place calls. type is
'peer' for incoming only
; & 'user' for outgoings only
context=outcoming-sip
host=dynamic ;
secret=1234 ; Password
nat=yes
qualify=yes
;bindport=5061
canreinvite=no
videosupport=yes
callgroup=1
pickupgroup=1
dtmfmode=auto
disallow=all ; users will choose wrong codecs if allow=all
allow=alaw
allow=ulaw
allow=gsm
allow=g729
allow=Speex
allow=h261
allow=h263
allow=h263p
;allow=g711u
allow=h264
[Manager](office-phones)
callerid="Manager" <800> ; Registering user 'Rakib' with phone
no. '800'
[2nd-manager](office-phones)
callerid="2nd-manager" <801> ; Registering user '2nd-
manager' with phone no. '801'

Page | 8
[towfiq](office-phones)
callerid="Towfiq" <802> ; Registering user 'Towfiq' with
phone no. '802'
[rakib](office-phones)
callerid="Rakib" <803> ; Registering user 'Rakib' with phone
no. '803'
[farhad](office-phones)
callerid=”Farhad" <804> ; Registering user 'Farhad' with
phone no. '804'
[2nd-pc](office-phones)
callerid="2nd-pc" <805> ; Registering user '2nd-pc' with
phone no. '805'
[006](office-phones)
callerid="Guest" <806> ; Registering user 'Guest' with phone
no. '806'
no. '807'
no. '808'
[Server](office-phones)
callerid="Server" <809> ; Registering user 'Server' with
phone no. '809'

Page | 9
Extensions configuration file (extensions.conf)
; :::::::::::::::::::::::::::::::::::::::::::::
; ::::::: :: Dialplan :: ::::::::
; :::::::::::::::::::::::::::::::::::::::::::::
; Registering numbers in extensions.conf
[general]
static=yes
writeprotect=no
clearglobalvars=no
[subscriber-sip]
exten => 800,1,Log(NOTICE,"800 ACCOUNT")
exten => 800,2,Dial(SIP/Manager,120,Tt)
exten => 801,2,Dial(SIP/001,120,Tt)
exten => 805,2,Dial(SIP/2nd-pc,120,Tt)
exten => 809,2,Dial(SIP/Server,120,Tt)
[hangup-sip]
exten => _X!,1,HangUp()
[outcoming-sip]
include => subscriber-sip
include => hangup-sip

Page | 10
RTP configuration:
If there is a Firewall between the Asterisk and the Network Server, this file have to be
configured to forward the configured ports.
In lab we have allocated the port numbers from 25008 – 25027. So the ‘rtpstart = 25008’ and
‘rtpend = 25025’. Now the question is why we use ‘rtpend’ 25025 where we have range upto
25027?
The answer is the first port number must be even number in the configuration file. We have
25008. And the last port number must be defined an odd number. Because Asterisk will
automatically use the next even number for its last port range. For our project our last range is
25027. But we have configured 25025 as asterisk will use 25026 as it’s last port range.
RTP configuration file (rtp.conf)
;
; RTP Configuration
;
[general]
;
; RTP start and RTP end configure start and end addresses
;
rtpstart=25008
rtpend=25025
SIP (Session Initiation protocol):
In the world of VoIP, SIP is a call setup protocol that operates at the application layer. SIP can
use either TCP or UDP. The reason of using UDP for this project is its header is smaller
compared to the TCP which increases the speed of the performance. From the figures we can
see that UDP header size is 8 bytes where TCP header needs 2.5 times of size i.e. 20 bytes.
TCP Header UDP Header

Page | 11
Fig 2: A SIP message header captured by Wireshark
The first line contains the version number of SIP that is used and the response code and name.
The lines that follow are a list of header fields. The ‘Via’, To, From, Call-ID, and CSeq header
fields are copied from the INVITE request. This shows that rakib invites too called party 800 and
the ‘via’ is the server 139.6.19.140. 800's SIP phone has added a tag parameter to the ‘To’
header field. This tag is incorporated by both endpoints into the dialog and is included in all
future requests and responses in this call.

Page | 12
Fig 3: A SDP captured by Wireshark
Session Description Protocol
The Session Description Protocol (SDP), defined in RFC 2327, describes the content of
sessions, including telephony, Internet radio, and multimedia applications. SDP includes
information about:
Media streams: A session can include multiple streams of differing content. In our project
we can see video and audio streams from Media Description tag.
Addresses: SDP indicates the destination addresses, which may be a multicast address,
for a media stream.
Ports: For each stream, the UDP port numbers for sending and receiving are certain
during a certain call session. For audio stream the port no here is 25008, media protocol is
RTP/AVP and some supported media codec formats. For video the port no. is 25018 here.

Page | 13
Payload types: For each media stream type in use (for example, telephony), the payload
type indicates the media formats that can be used during the session.
Start and stop times: These apply to broadcast sessions, for example, a television or
radio program. The start, stop, and repeat times of the session are indicated.
Originator: For broadcast sessions, the originator is specified, with contact information.
This may be useful if a receiver encounters technical difficulties.
Although SDP provides the capability to describe multimedia content, it lacks the mechanisms
by which two parties agree on the parameters to be used. RFC 3264 remedies this lack by
defining a simple offer/answer model, by which two parties exchange SDP messages to reach
agreement on the nature of the multimedia content to be transmitted.
Real Time Control Protocol:
RTCP accompanies RTP and is used to transmit control information about the RTP session.
RTCP packets are send only from time to time since there is a recommendation that the RTCP
traffic should consume less than 5 percent of the session bandwidth.
The most important content types carried in RTCP packets include:
● information about call participants (for example, name)
● Statistics about the quality of the transmission (for example inter-arrival jitter and the
number of lost packets). The report sent by a participant who both sends and
receives data is called a sender report (SR), while reports sent by participants who
only receive RTP streams are called receiver reports (RR).
There is a rule that RTP should use an even UDP port number (e.g. 5000) and the related
RTCP should use the next odd port (e.g. 5001).
Registration:
Before we describe the flow of a typical SIP call, let's have a look at how SIP user agents
register with a SIP registrar. The example below shows a situation where an SIP softphone
(namely, the Antisip client) registers with an Asterisk PBX. The Asterisk's IP address is
10.10.1.99, while the client is at 10.10.1.13 and wants to register the telephone number 13.
In order to register, the SIP telephone needs the send the REGISTER request:

Page | 14
Fig 4: user registration
The registrar server will immediately reply with the provisional response "100 Trying". This
indicates that the request has been received (and thus the client does not need to retransmit it)
and that it is being processed. While processing the request, the registrar discovers that the
user agent needs to authenticate. It therefore responds with "401 Unauthorized". For the user
agent, this means that it has to send the REGISTER request once more, this time providing
authentication.
Call Setup process:
From the screenshot of Figure 5. we can clearly observe the call setup and successfully receive
process. Here we can see the caller party is the Smartphone (139.6.217.174) who sends an
INVITE request to the Asterisk server for the user 800@139.6.19.140. After 0.313 ms the server
sends a “401 unauthorized” status to the Smartphone. Actually it is a challenge from the server
to the Smartphone that the Smartphone must be authenticated by giving the user credentials.
Fig 5: Call setup process.
After 6.117 milliseconds the Smartphone reply the ACK to the Server and confirms its identity.
Then about 4.8 milliseconds later it requests gain INVITE to the same user. After that the server
sends the Smartphone “100 Trying status” as well as sends to the called party IP Phone an

Page | 15
INVITE request. Then about 7.6 ms later the IP Phone (called party) sends a “100 trying” status
to the server and about 20.1 ms later it sends “180 Ringing” status to the server. After that about
0.19 ms later the server send the Smartphone “180 Ringing” status.
The time difference between the first INVITE request from the Smartphone for a certain call
session and the “180 Ringing” status from the Asterisk server to the Smartphone is the “Call
setup time”. The time may vary for different call sessions but the status & request sequences
must be followed.
For this call session shown in the Figure 5 the calculated call setup time is:
(180 Ringing status to the caller - INVITE request from caller)
= (9.651341000 - 9.610775000) seconds
= 0.040566 seconds
= 40.566 ms
RTP analysis:
If we apply filter named ‘rtp’ the Wireshark IO graph will show the complete rtp flow incoming
and outgoing to and from the all devices that registered to the Asterisk server. If the unit of Y
axis is selected bits/Tick the IO graph will show the data flow in bits per Tick. If the Tick interval
is ‘1 sec’ along X axis, it will show data flow in bps.
As in Figure 6 it is showing rtp flow in bps (the black line) and the maximum bandwidth is
1200000 bps or 1200 kbps. It is measured when only two devices were registered. One is a
Hardphone and another is a smartphone. The red line graph is showing the voice data sending
by the Hardphone. Let’s take a closer look at the voice data.

Page | 16
Fig 6: Total RTP vs two users RTP
As in Figure 6. there are two filters applied to the IO graph.
Graph2: rtp&&ip.src==139.6.19.151&&udp.srcport==11570
Graph3: rtp&&ip.dst==139.6.218.112&&udp.dstport==40100
For 2nd Graph (the red line) here compared the rtp flow that produces from the Hardphone as a
source and the data is flowing through the source port 11570. Here the port 11570 is used for
the voice data only and as here it is filtered as source port then it is showing the voice data from
Hardphone (as sending data) only.
In Graph 3 (the green line) rtp flow that is entering the smartphone as a destination through the
destination port 40100. As port 40100 is registered for voice data for smartphone.
Here it is seen a small amount of data loss to the destination smartphone.

Page | 17
Fig 7: RTP comparison graph between source & destination
If the X axis is selected the tick interval to 1 ms per tick i.e. Tick interval is 0.001 sec then the
data flow for every milliseconds can be observed. The figure 7 shows that the voice data is
transmitting for every 20 ms and each time nearly 1800 bits of packets is transmitting. So the
required data rate is nearly {(1000/20) x 1800 bits/sec} = 90000 bps.
It can be observed that the both source & destination filters are switched on and there is no loss
can be seen in the figure 7. The destination voice wave is green in color is under the source
voice wave of red color.

Page | 18
Fig 7.1: Voice (red) data vs Video (green) data
Fig 8: Voice payload 20 ms interval

Page | 19
The next figure 9 shows some time delay. The voice source is transmitting nearly 1800 bits of
data every 20 ms interval (red color). But, the voice destination has received at some
milliseconds delay. As the voice source smartphone is connected to the asterisk server through
the FH Koeln VPN server & the smartphone’s internet is operating on LTE network, so this data
transfer delay occurs.
Transmission delay:
The transmission delay is the time required to insert all the packet bits to the transmission wire.
That means this depends on the data rate or bandwidth of the wire. Let’s say the given
bandwidth for the transmission wire is B and the total data or number of bits to be transferred
through the wire (or medium) is N. So the calculated delay D will be,
𝐷 =
𝑁
𝐵
Here,
D = store-and-forward delay
N = Total Number of bits per cycle
B = Bandwidth of the transmission medium
Most of the packet switch network uses store-and -forward transmission where it receives the
bits to its buffer, performs the CRC (Cyclic Redundancy Check) for errors or other problems and
then send the packets to the outbound link. This introduces store-and-forward delay.
Fig 9: voice payload source (red) vs destination phone (green)

Page | 20
The sum of total store-and-forward delay from transmitter to the receiving end is called packet
transfer delay. It depends on some factors.
● Transmission delay
● Queuing
● Propagation delay
● Nodal processing
Transmission delay we have already discussed about this delay. The transmission delay is the
time required to insert all the packet bits to the transmission wire.
Queuing: This kind of delay occurs when a transmitting signal waits in queue until it executed.
For the networks where there is switching component a delay time between the signal of call
initiator & the arrival of ringing signal to the call receiver. A router can process only one packet
at a time. When more than one packet come faster to the router then the router keeps the rest
of the packets in a queue.
Propagation delay: It is a kind of time delay for the head of the signal to travel from the sender
to the receiver. Propagation delay can be described as L / C where L is the length of the total
transmission line and C is the speed of propagation of a packet. So the Propagation delay Pd,
𝑃𝑑 =
𝐿
𝐶
Nodal Processing: It is the delay time to process a packet in network node (switch, router, hub)
which is dependent on the speed of the device and congestion in the network.
From above two figures a new term can be observed. Voice Payload is the number of bits that
are filled into a packet. For PCMU & PCMA codec it is 20 ms. From these figures we can see
the difference is exactly 20 ms between the two packets including some gap or no data state
which is called channel spacing.
Channel Spacing is a widely used & must containing term in Communication and Network
Systems. This space is a must use to avoid the interference between two different identical
signals. Otherwise interference will occur within the packets.
VoIP header = (IP + UDP + RTP) = 40 bytes in IPv4 and 60 bytes in IP version 6 (IPv6)
VoIP packet = (VoIP header + voice payload)
VoIP header Compressed voice payload
IP
Header
20 bytes
UDP
Header
12 bytes
RTP
Header
12 bytes
80 bytes G.711 (64 kbps)
80 bytes G.722 (64 kbps)
Fig 10: VoIP packet format with voice payload and headers.

Page | 21
Physical network VoIP packet = Network interface headers + (VoIP header + voice payload)
Voice payload varies with compression codec, payload duration, and compression rate options.
In some topics, bit rate (usually with name bandwidth) is calculated based on the VoIP packet
without including the network interfaces. As an example, for G.711 of 80 bytes in a 10-ms
frame, bit rate is considered as 120 bytes of 100 packets per second, (i.e., 100 x 120 x 8 =
96kbps). The actual bit rate requirements are more than 96 kbps on physical interfaces.
Following figures showing some codec payloads bitrate (Bandwidth) and their payload time.
This data have collected in the lab and have jitter and loss.
Fig 11: G.711 codec bandwidth (85kbps)

Page | 22
Fig 12: G.711 payload (20 ms)
Fig 13: gsm codec bandwidth (35 kbps)

Page | 23
Fig 14: gsm payload (20 ms)
Fig 15: G.722 codec bandwidth (86 kbps)

Page | 24
Fig 16: G.722 payload (20 ms)
Fig 17: H.263 bandwidth (220 kbps)

Page | 25
Fig 18: H.263 payload (70 ms)
Fig 19: H.264 bandwidth (230 kbps)

Page | 26
Fig 20: H.264 payload (70 ms)
Codec Bit Rate Payload (ms)
G.711 84 kbps 20 ms
gsm 35 kbps 20 ms
G.722 86 kbps 20 ms
H.263 220 kbps 70 ms
H.264 230 kbps 70 ms
Table 1: Measured bit rate & payload for different codecs
Codec Bit Rate (Kbps)
Based on the codec, this is the number of bits per second that need to be transmitted to deliver
a voice call. (Codec bit rate = codec sample size / codec sample interval)
Codec Sample Size (Bytes)
Based on the codec, this is the number of bytes captured by the Digital Signal Processor (DSP)
at each codec sample interval. For example, the G.729 coder operates on sample intervals of
10 ms, corresponding to 10 bytes (80 bits) per sample at a bit rate of 8 Kbps. (codec bit rate =
codec sample size / codec sample interval).

Page | 27
MOS
MOS is a system of grading the voice quality of telephone connections. With MOS, a wide range
of listeners judge the quality of a voice sample on a scale of one (bad) to five (excellent). The
scores are averaged to provide the MOS for the codec.
Voice Payload Size (ms)
The voice payload size can also be represented in terms of the codec samples. For example, a
G.729 voice payload size of 20 ms (two 10 ms codec samples) represents a voice payload of 20
bytes [ (20 bytes * 8) / (20 ms) = 8 Kbps ]
PPS
PPS represents the number of packets that need to be transmitted every second in order to
deliver the codec bit rate. For example, for a G.729 call with voice payload size per packet of 20
bytes (160 bits), 50 packets need to be transmitted every second [50 pps = (8 Kbps) / (160 bits
per packet) ]
Bandwidth Calculation Formulas
These calculations are used:
● Total packet size = (L2 header: MP or FRF.12 or Ethernet) + (IP/UDP/RTP header) +
(voice payload size)
● PPS = (codec bit rate) / (voice payload size)
● Bandwidth = total packet size * PPS
Sample Calculation
For example, the required bandwidth for a G.729 call (8 Kbps codec bit rate) with cRTP, MP and
the default 20 bytes of voice payload is:
● Total packet size (bytes) = (MP header of 6 bytes) + ( compressed IP/UDP/RTP header
of 2 bytes) + (voice payload of 20 bytes) = 28 bytes
● Total packet size (bits) = (28 bytes) * 8 bits per byte = 224 bits
● PPS = (8 Kbps codec bit rate) / (160 bits) = 50 pps
● Note: 160 bits = 20 bytes (default voice payload) * 8 bits per byte
● Bandwidth per call = voice packet size (224 bits) * 50 pps = 11.2 Kbps
Final measurements:
The following figures are showing the complete RTP stream captured for 60 seconds call
session by Wireshark. In figure 21 It has detected in total of 8 RTP streams. To get this window
in Wireshark go to menu tab and select Telephony > RTP > Show All Streams. This window will
show all RTP streams including source and destination ports for both parties (caller & called)
with the total packets corresponds to the payload, packet loss and jitter. Observing this figure
we can realize that from the Smartphone to the IP phone we found 28 (0.9%) voice (g711A)
packets lost and 25 (1.4%) video (h263) packets lost during 60 seconds of call session. That

Page | 28
means the video packet loss is much more than the audio packet loss. It can be stated that the
Smartphone is on LTE/3G network and connected to the server through the VPN.
The maximum mean jitter can be found 6.02 ms and 6.02 ms which are the video (h263)
packets those originates from the IP Phone and ends at the Smartphone.
The minimum mean jitter can be found 1.41 ms which are the audio packets from the IP Phone
to the Smartphone.
The IP Phone (139.6.19.151) uses port no. 40512 to send and receive audio (g711A) packets
and 5062 (na-localise) for sending & receiving video packets (h263).
On the other hand the Smartphone (139.6.217.174) always uses port 4100 to send & receive
audio (g711A) packets and port 40120 to send & receive video (h263) packets.
Fig 21: A Complete RTP stream captured by Wireshark (Sesion 1)
Now the Asterisk server (139.6.19.140). It uses port 25024 to send & receive audio (g711A)
packets to & from the IP Phone. When it uses port 25026 (na-localise) to send & receive video
(h263) packets to & from the IP Phone.
On the other hand the server uses port 25016 for voice packets to & from the smartphone and
port 25014 for video packets to & from the Smartphone.
However, there is no P2P connection between the two phones (IP Phone & Smartphone). Both
the phone always sends and receives voice & video data through the asterisk server.
It also can be observed that there is no packet loss from the IP phone & the Asterisk server
rather than from the Smartphone. Which means the problem is on the LTE/3G transmission line
which make loss of packets.

Page | 29
Bellow here 5 more 60 seconds call observations.

Page | 30

Page | 31
From these above 6 tests we can see there is only packet loss from the incoming data from
Smartphone connected through the VPN. The following table is showing the comparisons of
packet loss and mean jitter among these tests for the outgoing media streams of the
Smartphone.
Session Payload type Packets lost Packet loss % Mean Jitter (ms)
1
G711A 28 0.9 2.42
H263 25 1.4 4.53
2
G711A 26 0.9 0.20
H263 21 1.2 0.80
3
G711A 34 1.1 2.46
H263 17 1.0 3.80
4
G711A 33 1.0 1.75
H263 8 0.4 2.55
5
G711A 29 0.9 3.52
H263 59 3.2 5.41
6
G711A 33 1.1 1.94
H263 9 0.5 3.04
Table 2: Comparison of 6 sessions of calls each for 60 seconds

Page | 32
Figure 27: G711A vs H263 Packet loss
Fig 28: G711A vs H263 Mean Jitter
0
10
20
30
40
50
60
70
G711A Packet Loss H263 Packet Loss
G711A vs H263 Packet loss
Session 1 Session 2 Session 3 Session 4 Session 5 Session 6
0
1
2
3
4
5
6
G711A Mean Jitter H263 Mean Jitter
G711A vs H263 Mean Jitter
Session 1 Session 2 Session 3 Session 4 Sesion 5 Session 6

Page | 33
Conclusion:
We have successfully established and executed the video and audio call session within the
LTE/3G network using the SIM card from an operator. There was some loss about 1% – 3% but
it is tolerable. The jitter is also within tolerance max 5.4 ms. but the result is satisfactory. We
have a future plan to extend this work to connect all the students within the university network
using their individual Matrikel number as their phone number within a privet switch network.
References:
1) Display filter references for Wireshark IO graph:
https://www.wireshark.org/docs/dfref/
2) RTP Statistics
https://wiki.wireshark.org/RTP_statistics
3) VoIP protocols : SIP messages
http://toncar.cz/Tutorials/VoIP/VoIP_Protocols_SIP_Messages.html
4) How to install Asterisk on Ubuntu:
http://blogs.digium.com/2012/11/14/how-to-install-asterisk-11-on-ubuntu-12-4-lts/
5) Asterisk creating sip-accounts:
https://wiki.asterisk.org/wiki/display/AST/Creating+SIP+Accounts
6) Wireshark User’s Guide:
http://www.wireshark.org/docs/wsug_html_chunked/J

Setup VoIP System and Interconnection with LTE network

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to Setup VoIP System and Interconnection with LTE network

Similar to Setup VoIP System and Interconnection with LTE network (20)

Recently uploaded

Recently uploaded (20)

Setup VoIP System and Interconnection with LTE network