Setup VoIP System and Interconnection with LTE network

Setting up VoIP management server

using Asterisk communication framework

and let the users from LTE networks to

register and make voice calls over IP

system as well as video session

Setup VoIP System and Interconnection with LTE network A corporate step

Mohammad Nazmul Hossain Mohammad Farhad Hossain Towfique Imam Chowdhury

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 [email protected]. 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

https://www.wireshark.org/docs/dfref/

https://wiki.wireshark.org/RTP_statistics

http://toncar.cz/Tutorials/VoIP/VoIP_Protocols_SIP_Messages.html

http://blogs.digium.com/2012/11/14/how-to-install-asterisk-11-on-ubuntu-12-4-lts/

https://wiki.asterisk.org/wiki/display/AST/Creating+SIP+Accounts

http://www.wireshark.org/docs/wsug_html_chunked/J

Setup VoIP System and Interconnection with LTE network

Engineering

Transcript of Setup VoIP System and Interconnection with LTE network