Task

The objective of this experiment is to capture all IP packets sent to and received
from two hosts over the course of a video conference and analyze the RTP and
RTCP packets captured during this process. Data is captured both at both hosts for
two calls, once during low network load and once when network load is high.
For our experiment, Googles Hangouts was initially used to establish a call but
their deviation from RFC 3550 standards and use of encryption made it difficult to
analyze the recorded data. Go2Meeting was used next and we discovered that
they too employed encryption, making analysis difficult. Therefore we resorted to
the use of Linphone, an open source VoIP project supported by Belledonne
Communications.

Experiment conditions
Host 1

Host 2

Location

New Brunswick

East Brunswick

Device used

Personal Laptop

Personal Laptop

ISP

Optimum

Comcast

Public IP

68.193.145.122

68.44.24.247

IP in local network

192.168.1.7

192.168.2.72

Trial one
Date: 11/4/2014 Time: 11:10 PM

Network Conditions: Low Traffic

Trial two
Date: 11/6/2014 Time: 2:11 PM

Network Conditions: High Traffic

The Process
The First step was to setup a video call from host 1 to host 2 with encryption
disabled. This was achieved by setting the Media encryption type in the network
settings tab in the Preferences window to None.
After the call was setup, all transmitted data was captured using wireshark. We
decided to capture data for 10 minutes, so the stop capture automatically after
option in the capture options page was set to stop after 10 minutes.
The capture process was performed at both hosts simultaneously and the data
was stored to a pcapng file.
The capture of the second call was performed with intervals where, one of the
Hosts mic was deactivated and then the other host had his mic de-activated and
then the both mic were deactivated. During the periods when the mic was
deactivated, the video was also disabled. Video could not be disabled for one
source at a time as Linphone provided no such feature.
Identifying RTP packets
All captured RTP and RTCP packets are simply displayed as UDP packets in
wireshark. To identify our RTP and RTCP packets, Wiresharks Decode as feature
was used. When used on a single packet, it is capable of identifying all packets in
that particular stream (data to and from the source and destination ports
specified in that packet). To successfully decode all RTP packets, we initially
filtered out data that was still interpreted as UDP and not as RTP or RTCP using
the display filter
udp and not(rtp) and not(rtcp)
Linphone allows us to specify what ports are to be used for audio and video
communication, so this allows us to spot RTP packets and then the decode as'
function can be used to make wireshark identify the RTP packets. Upon exploring
we identified that Linphone follows standard conventions and transmits RTCP
packets from the next higher up odd numbered port for each source. This was
used to identify and decode the RTCP packets.

All necessary data was added to columns and were exported to a csv file. Excel
was used to calculate all necessary statistics.
Identifying Payload type
Initial plan for identifying Payload types was based on the fact that Audio data
occupies lesser space than video data. So, we expected the overall space occupied
by the packets of the audio stream to be lesser than that occupied by the video
stream.
But with the use of linphone, we were able to manually set Audio and Video
ports. So to identify payload type, one can simply look into the details of any
packet sent from a particular port and associate that payload type to the purpose
of that port.
Network paths
Upon capturing the data and identifying the IP of the server used by Linphone,
Tracert was used to identify the path from the hosts to the server.
1. Path from Host 1 to Linphone Server

2. Path from Host 2 Linphone Server

Statistics
Session 1: Host 1
Session Duration=10 Minutes, Session completed using LINPHONE with both
audio and video turned ON for the entire duration.
Source Destination Number of
Port(1)
Port(1)
Packets(2)
9078
7078

55388
62842

11014
29988

9079

55389

120

7079

62843

120

Source Destination Number of

Port(1)
Port(1)
Packets(2)
55388
62842

9078
7078

11877
29900

55389

9079

120

62843

7079

120

Host 1 Outgoing
RTP Packet Size(3)
Lost
Mean Time Between Two
Payload
(Length in Bytes)
SSRC Identifiers(5) Packets
Packets(s)(7)
Type(4)
(6)
Min Max
Mean
Min
Max
Mean
56.0 1294.0 1043.57458 RTPType-103 0x2CE7
0 0.000031 0.232708 0.05443793
88.0 136.0 103.26740 RTPType-124 0x6D9E
0 0.000031 0.050535 0.01999859
0x2CE7(Sender)
146.0 146.0 146.00000
0
0x687B(First source)
4.912988 5.031413 4.99930410
SR(200)
0x6D9E(Sender)
146.0 146.0 146.00000
0
4.989735 5.010318 4.99988136
0x2DC0(First Source)

Host 1 Incoming
RTP Packet Size(3)
Lost
Mean Time Between Two
Payload
(Length in Bytes)
SSRC Identifiers(5) Packets
Packets(s)(7)
Type(4)
(6)
Min Max
Mean
Min
Max
Mean
56.0 1294.0 1027.18426 RTPType-103 0x687B
34 0.000011 2.783036 0.05048929
74.0 136.0
92.38416 RTPType-124 0x2DC0
84 0.000011 2.747859 0.02005557
0x687B(Sender)
150.0 150.0 150.00000
0
0x2CE7(First source)
2.957019 7.048796 5.00016892
SR(200)
0x2DC0(Sender)
150.0 150.0 150.00000
0
4.950914 5.039732 5.00024492
0x6D9E(First Source)

Host 2
Source
Port(1)

Destination
Port(1)

9078
7078

35248
57170

9079

35249

7079

57171

Source
Port(1)

Destination
Port(1)

57170
35248

9078
7078

35249

9079

57171

7079

Host 2 Outgoing
RTP Packet Size(3)
Number of
Payload
(Length in Bytes)
SSRC Identifiers(5)
Packets(2)
Type(4)
Min Max
Mean
11906 56.0 1294.0 1043.5746 RTPType-103 0x687B
29972 88.0 136.0
103.2674 RTPType-124 0x2DC0
0x687B(Sender)
120 150.0 150.0
150.0000
0x2CE7(First source)
SR(200)
0x2DC0(Sender)
120 150.0 150.0
150.0000
0x6D9E(First Source)

Host 2 Incoming
RTP Packet Size(3)
Number of
Payload
(Length in Bytes)
SSRC Identifiers(5)
Packets(2)
Type(4)
Min Max
Mean
10968 56.0 1294.0 1027.18426 RTPType-103 0x2CE7
29928 74.0 136.0
92.38416 RTPType-124 0x6D9E
0x2CE7(Sender)
120 146.0 146.0 146.00000
0x687B(First source)
SR(200)
0x6D9E(Sender)
120 146.0 146.0 146.00000
0x2DC0(First Source)

Lost
Mean Time Between Two
Packets
Packets(s)(7)
(6)
Min
Max
Mean
0 0.000030 0.344843 0.05034288
0 0.000027 0.067819 0.01999939
0

4.974013 5.021175 5.00007882

0 4.987259 5.023026 5.00003308

Lost
Mean Time Between Two
Packets
Packets(s)(7)
(6)
Min
Max
Mean
41 0.000020 0.636363 0.05465503
48 0.000018 0.525384 0.02002977
0 4.805372 5.156351 4.99952360
0

4.822684 9.965048 5.04177715

Session 2: Host 1:
Session Duration=10 Minutes, Session completed using LINPHONE with audio and
video transmission changed according to the following table
Duration in secs
Audio
Host 1 Video
Audio
Host 2 Video

Source
Port(1)

Destination
Port(1)

9078

22512

7078

48084

0-100
ON
ON
ON
ON

Number of
Packets(2)
2018
3930
5068
15424
9849
20

9079

22513
40
20

7079

48085

64
40

100-220
ON
OFF
OFF
OFF

220-340
OFF
OFF
ON
OFF

340-460
OFF
OFF
OFF
OFF

460-600
ON
ON
ON
ON

Host 1 Outgoing
RTP Packet Size(3)
Payload
SSRC Identifiers
(Length in Bytes)
Type(4)
(5)
Min Max
Mean
56.0 1294.0
976.5970
0x6F50
RTPType-103
56.0 1294.0
962.4204
0x604
76.0 124.0
103.4417
0x1478
75.0 126.0
84.8048 RTPType-124 0x1288
76.0 126.0
102.3511
0x40EB
0x6F50(Sender)
146.0 146.0
146.0000
0x7C7B(First source)
0x604(Sender)
146.0 146.0
146.0000
0x11A6(First source)
0x1478(Sender)
146.0 146.0
146.0000
SR(200)
0x7632(First Source)
0x1288(Sender)
146.0 146.0
146.0000
0x7280(First source)
0x40EB(Sender)
146.0 146.0
146.0000
0x11A6(First source)

Lost
Packets
(6)
0
0
0
0
0

Mean Time Between Two

Packets(s)(7)
Min
Max
Mean
0.000049 0.215294
0.046690
0.000045 0.212085
0.046743
0.000042 0.076238
0.020001
0.000040 0.095160 0.02000033
0.000032 0.070331
0.019997

0 4.990815 5.008854 5.00021237

0 2.433994 5.018551 4.67089231
0
0 2.458975 6.110196 4.80674951
0

Source
Port(1)

Destination
Port(1)

22512

9078

48084

7078

Number of
Packets(2)
2171
3985
5071
15413
9839
20

22513

9079
40
20

48085

7079

64
40

Host 1 Incoming
RTP Packet Size(3)
Payload
(Length in Bytes)
SSRC Identifiers(5)
Type(4)
Min Max
Mean
57.0 1294.0 1045.02150
0x7C7B
RTPType-103
57.0 1294.0 1051.96938
0x11A6
75.0 128.0
90.29000
0x7632
74.0 130.0
79.85449 RTPType-124 0x7280
74.0 137.0
83.93721
0x6A38
0x7C7B(Sender)
150.0 150.0
150.0000
0x6F50(First source)
0x11A6(Sender)
150.0 150.0
150.0000
0x604(First source)
0x7632(Sender)
150.0 150.0
150.0000
SR(200)
0x1478(First Source)
0x7280(Sender)
150.0 150.0
150.0000
0x1288(First source)
0x11A6(Sender)
150.0 150.0
150.0000
0x40EB(First source)

Lost
Packets
(6)
7
12
12
28
4

Mean Time Between Two

Packets(s)(7)
Min
Max
Mean
0.000021 0.274938
0.050360
0.000021 0.585956 0.05125664
0.000019 0.227115 0.02052235
0.000020 0.297903 0.02100480
0.000019 0.560520
0.020008

0 4.896326 5.115281 4.99939095

0 2.494215 5.018851 4.73670282
0
0 2.4796

8.63646

4.8873041

Host 2:
Source
Port(1)

Destination
Port(1)

9078

27940

7078

19518

Number of
Packets(2)
2167
3997
5060
15425
9452
20

9079

27941
40
20

7079

19519

64
40

Source
Port(1)

Destination
Port(1)

27940

9078

19518

7078

Number of
Packets(2)
2000
3659
5044
15396
9445
20

9079

27941
40
20

7079

19519

64
40

Host 2 Outgoing
RTP Packet Size(3)
Payload
SSRC Identifiers
(Length in Bytes)
Type(4)
(5)
Min Max
Mean
56.0 1294.0
976.5970
0x7C7B
RTPType-103
56.0 1294.0
962.4204
0x11A6
76.0 124.0
103.4417
0x7632
75.0 126.0
84.8048 RTPType-124 0x7280
76.0 126.0
102.3511
0x6A38
0x7C7B(Sender)
150.0 150.0
150.0000
0x6F50(First source)
0x11A6(Sender)
150.0 150.0
150.0000
0x604(First source)
0x7632(Sender)
150.0 150.0
150.0000
SR(200)
0x1478(First Source)
0x7280(Sender)
150.0 150.0
150.0000
0x1288(First source)
0x11A6(Sender)
150.0 150.0
150.0000
0x40EB(First source)
Host 2 Incoming
RTP Packet Size(3)
Payload
(Length in Bytes)
SSRC Identifiers(5)
Type(4)
Min Max
Mean
57.0 1294.0 1044.02150
0x6F50
RTPType-103
57.0 1294.0 1052.96938
0x604
75.0 128.0
90.14000
0x1478
74.0 130.0
79.63449 RTPType-124 0x1288
74.0 137.0
85.93721
0x40EB
0x6F50(Sender)
146.0 146.0
146.0000
0x7C7B(First source)
0x604(Sender)
146.0 146.0
146.0000
0x11A6(First source)
0x1478(Sender)
146.0 146.0
146.0000
SR(200)
0x7632(First Source)
0x1288(Sender)
146.0 146.0
146.0000
0x7280(First source)
0x40EB(Sender)
146.0 146.0
146.0000
0x11A6(First source)

Lost
Packets
(6)
0
0
0
0
0

Mean Time Between Two

Packets(s)(7)
Min
Max
Mean
0.000049 0.215294
0.046690
0.000045 0.212085
0.046743
0.000042 0.076238
0.020001
0.000040 0.095160 0.02000033
0.000032 0.070331
0.019997

0 4.990815 5.008854 5.00021237

0 2.433994 5.018551 4.67089231
0
0 2.458975 6.110196 4.80674951
0

Lost
Packets
(6)
7
12
12
28
4

Mean Time Between Two

Packets(s)(7)
Min
Max
Mean
0.000021 0.274938
0.050460
0.000021 0.585956 0.05153664
0.000019 0.227115 0.02004235
0.000020 0.297903 0.02003480
0.000019 0.560520
0.020008

0 4.896326 5.115281 4.99939095

0 2.494215 5.018851 4.73670282
0
0 2.4796
0

8.63646

4.8873041

Observations and Analysis

Following are the comments on each column of the above statistics and
recordings tables.

(1) The software used for the conference was LINPHONE. This is an open
source software with a lot of options. The encryption option was disabled
for this experiment. The port pairs were chosen to be 7078 for audio and
9078 for video on both PCs. The UDP traffic is directed from one
participant PC to LINPHONE servers. The data is then transmitted to other
participants PC. The server does not seem to perform any processing of its
own. Since the SSRC identifiers remain intact for all packets, it appears that
the traffic does not pass through any mixers. Both the participant connect
to the same LINPHONE server, in our case it was 91.121.209.194.
The Packets were decoded to be RTP/RTCP by Wireshark Decode As
option. However, it was confirmed that the decoding of Wireshark was
correct by reviewing that the UDP port pairs used by the software were
strictly in accordance with RFC 3550. I.e. even numbered port was used for
RTP packets and the next higher odd numbered port was used for the
RTCP packets. The tables show the exact values of all UDP port pairs as
used by RTP/RTCP packets in this experiment.
(2) Audio packets seem to be larger in number and transmitted more
frequently than video packets. But video packets are longer than Audio
Packets. Based on the first session, mean time between packets is almost
constant for audio and video at .02s and .05s each. And Sizes are also
almost similar with audio packets sized around 100 bytes and video
packets sized around 1000 bytes.
This makes audio packets more in number by a factor of 2.5 and smaller
than video packets by a factor close to 10. So Video data makes up close to
80% of our data traffic ignoring the RTCP packets which with a mean time

of 5 seconds between each packet and a fixed packet size close 150 bytes
occupy a very small portion of the traffic.
It is worth mentioning that in session two, when video was disabled, no
packets were transmitted but while audio was muted, transfer still
occurred.
(3) The criteria for identifying the audio packets is that RTP audio packets are
smaller in size and usually larger in number and transmitted at a higher
rate as compared to RTP video packets, which are larger in size, still large
in number but smaller than RTP audio packets and have less rate of
transmission of packets.
RTCP packets coming from a particular source are always of the same
length (146 in the case of host 1 and 150 in the case of host 2). This can be
explained based on the fact the main message carries only blocks of fixed
length. The length can increase based on the number of report blocks, but
both carry only one at all times. The difference of 4 bytes between the two
RTCP packets comes from the Chunk added to the end by Linphone. This
chunk contains user data and that includes the users Local IP as text. A
difference in the number of digits between the two hosts IPs causes its
length to increase by 4 bytes.

a. End of Host 2s RTCP packet

End of Host 1s RTCP packet

(4) The Payload Type for RTP (both audio and video) packets is assigned in the
dynamic PT range which is 96-127. The statistics of packets sizes can be
found in the respective tables.

(5) SSRC identifiers identify each device in a session. SSRC identifiers seem to
be assigned randomly at the beginning of a session. All devices in the two
sessions were observed to have a unique SSRC identifier.

Whenever a device is turned off for a while and then reactivated, it seems
to receive a new SSRC identifier. This should explain the different sender,
first source combinations in the SSRC identifier column of the observations
in the second session.
The SSRC identifiers are used to uniquely identify each device in a session.
This SSRC identifier is randomly assigned at the beginning of each session.
No two devices in a session can have the same SSRC identifier. For our two
sessions, all devices were observed to have unique SSRC identifiers.
The Sender Report contain the SSRC identifier of the device sending the
RTP stream as well as the device at remote end sending similar RTP stream
but in other direction. This is exactly what can be observed from the tables.
As an example, the sender report sent from Camera of participant 1(SSRC
identifier: 0x687B) contains SSRC identifier as 0x687B and its first source
field contains the SSRC identifier of the camera of PC2 (SSRC Identifier:
0x2CE7). Similar is the case for the other device i.e. Mic.

(6) Packet loss is observed only in the incoming streams. It is logical to assume
that this is because the loss occurs during transmission and host 1 can only
detect loss in the stream it received from host 2 and similarly, only host 2
can detect the loss in the stream from host 1.
A correlation could not be made between packet loss and network load as
they seem to vary irrespective of network load.
(7) Since the algorithm for computing the RTCP packets transmission interval
takes into consideration the dynamic changing of number of participant in
a session, this did not affect our observations. Since the number of
participants was only two and the transmission bandwidth was considered
to be stable, the interval between Sender Reports was nearly constant
with a mean of almost 5 Seconds.

The time between two consecutive packets indicated in the outgoing

tables reflect the time between the transmissions of two packets, but the
time between two packets observed in the incoming tables reflects the
difference between the times when two packets are received by a host.
Any discrepancy between incoming statistics of one host and the
corresponding outgoing statistics of the other host must be caused by
network conditions.
In our observations, we noticed that the mean times between
corresponding incoming and outgoing streams vary more when the
network has a higher load.
For Instance, The following table contains the mean times between
packets for Host 1s incoming stream and Host 2s outgoing stream for
both sessions. Notice how Session 2 has a greater change in mean times,
while session 1 shows smaller changes.

This shows how the difference in mean times is greater during periods of higher
traffic load. This difference in means in this case is low enough to be
compensated with other techniques but greater changes can cause a drop in
quality.

References
1. http://www.ece.rutgers.edu/~marsic/books/CN/projects/wireshark/wsproject-3.html
2. http://www.ietf.org/rfc/rfc3550.txt
3. http://www.networksorcery.com/enp/protocol/rtp.htm
4. http://en.wikipedia.org/wiki/Real-time_Transport_Protocol