analysis of rtp and rtcp packets in wireshark

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, Google’s 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, Wireshark’s 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.

Min Max Mean Min Max Mean

9078 55388 11014 56.0 1294.0 1043.57458 RTPType-103 0x2CE7 0 0.000031 0.232708 0.05443793

7078 62842 29988 88.0 136.0 103.26740 RTPType-124 0x6D9E 0 0.000031 0.050535 0.01999859

9079 55389 120 146.0 146.0 146.000000x2CE7(Sender)

0x687B(First source)0

4.912988 5.031413 4.99930410

7079 62843 120 146.0 146.0 146.000000x6D9E(Sender)

0x2DC0(First Source)0

4.989735 5.010318 4.99988136

Host 1 Outgoing

RTP Packet Size(3)

(Length in Bytes)Payload

Type(4)

SR(200)

Destination

Port(1)

Number of

Packets(2)

Mean Time Between Two

Packets(s)(7)SSRC Identifiers(5)

Lost

Packets

(6)

Source

Port(1)


55388 9078 11877 56.0 1294.0 1027.18426 RTPType-103 0x687B 34 0.000011 2.783036 0.05048929

62842 7078 29900 74.0 136.0 92.38416 RTPType-124 0x2DC0 84 0.000011 2.747859 0.02005557

55389 9079 120 150.0 150.0 150.000000x687B(Sender)

0x2CE7(First source)0

2.957019 7.048796 5.00016892

62843 7079 120 150.0 150.0 150.000000x2DC0(Sender)

0x6D9E(First Source)0

4.950914 5.039732 5.00024492

Destination

Port(1)

Number of

Packets(2)

Payload

Type(4)SSRC Identifiers(5)

Lost

Packets

(6)

SR(200)

Host 1 Incoming

RTP Packet Size(3)

(Length in Bytes)


Packets(s)(7)Source

Port(1)

Host 2

Session 2: Host 1:

Session Duration=10 Minutes, Session completed using LINPHONE with audio and

video transmission changed according to the following table


9078 35248 11906 56.0 1294.0 1043.5746 RTPType-103 0x687B 0 0.000030 0.344843 0.05034288

7078 57170 29972 88.0 136.0 103.2674 RTPType-124 0x2DC0 0 0.000027 0.067819 0.01999939

9079 35249 120 150.0 150.0 150.00000x687B(Sender)

0x2CE7(First source)0

4.974013 5.021175 5.00007882

7079 57171 120 150.0 150.0 150.00000x2DC0(Sender)

0x6D9E(First Source)0 4.987259 5.023026 5.00003308


Packets(s)(7)SSRC Identifiers(5)

Lost

Packets

(6)

Host 2 Outgoing

RTP Packet Size(3)


Type(4)

SR(200)

Destination

Port(1)

Number of

Packets(2)

Source

Port(1)


57170 9078 10968 56.0 1294.0 1027.18426 RTPType-103 0x2CE7 41 0.000020 0.636363 0.05465503

35248 7078 29928 74.0 136.0 92.38416 RTPType-124 0x6D9E 48 0.000018 0.525384 0.02002977

35249 9079 120 146.0 146.0 146.000000x2CE7(Sender)

0x687B(First source)0 4.805372 5.156351 4.99952360

57171 7079 120 146.0 146.0 146.000000x6D9E(Sender)

0x2DC0(First Source)0

4.822684 9.965048 5.04177715

Destination

Port(1)


Packets(s)(7)

SR(200)

Host 2 Incoming

RTP Packet Size(3)

(Length in Bytes)Number of

Packets(2)

Payload


Lost

Packets

(6)

Source

Port(1)

0-100 100-220 220-340 340-460 460-600

Audio ON ON OFF OFF ON

Video ON OFF OFF OFF ON

Audio ON OFF ON OFF ON

Video ON OFF OFF OFF ON

Host 1

Host 2

Duration in secs


2018 56.0 1294.0 976.5970 0x6F50 0 0.000049 0.215294 0.046690

3930 56.0 1294.0 962.4204 0x604 0 0.000045 0.212085 0.046743

5068 76.0 124.0 103.4417 0x1478 0 0.000042 0.076238 0.020001

15424 75.0 126.0 84.8048 0x1288 0 0.000040 0.095160 0.02000033

9849 76.0 126.0 102.3511 0x40EB 0 0.000032 0.070331 0.019997

20 146.0 146.0 146.00000x6F50(Sender)

0x7C7B(First source)0 4.990815 5.008854 5.00021237

40 146.0 146.0 146.00000x604(Sender)

0x11A6(First source)0 2.433994 5.018551 4.67089231

20 146.0 146.0 146.00000x1478(Sender)

0x7632(First Source)0

64 146.0 146.0 146.00000x1288(Sender)

0x7280(First source)0

40 146.0 146.0 146.00000x40EB(Sender)

0x11A6(First source)0

480857079

SSRC Identifiers

(5)

Lost

Packets

(6)

RTPType-103

SR(200)

6.110196 4.806749512.458975

RTPType-124

Host 1 Outgoing

RTP Packet Size(3)


Type(4)

Destination

Port(1)

Number of

Packets(2)

Source

Port(1)


Packets(s)(7)

9079 22513

9078 22512

7078 48084

Host 2:


2171 57.0 1294.0 1045.02150 0x7C7B 7 0.000021 0.274938 0.050360

3985 57.0 1294.0 1051.96938 0x11A6 12 0.000021 0.585956 0.05125664

5071 75.0 128.0 90.29000 0x7632 12 0.000019 0.227115 0.02052235

15413 74.0 130.0 79.85449 0x7280 28 0.000020 0.297903 0.02100480

9839 74.0 137.0 83.93721 0x6A38 4 0.000019 0.560520 0.020008

20 150.0 150.0 150.00000x7C7B(Sender)

0x6F50(First source)0 4.896326 5.115281 4.99939095

40 150.0 150.0 150.00000x11A6(Sender)

0x604(First source)0 2.494215 5.018851 4.73670282

20 150.0 150.0 150.00000x7632(Sender)


64 150.0 150.0 150.00000x7280(Sender)


40 150.0 150.0 150.00000x11A6(Sender)

0x40EB(First source)0

Host 1 Incoming


Packets(s)(7)Payload


Lost

Packets

(6)

Destination

Port(1)

RTP Packet Size(3)


Packets(2)

Source

Port(1)

22512 9078

2.4796 8.63646 4.8873041

22513 9079

SR(200)

48085 7079

48084 7078

RTPType-103

RTPType-124


2167 56.0 1294.0 976.5970 0x7C7B 0 0.000049 0.215294 0.046690

3997 56.0 1294.0 962.4204 0x11A6 0 0.000045 0.212085 0.046743

5060 76.0 124.0 103.4417 0x7632 0 0.000042 0.076238 0.020001

15425 75.0 126.0 84.8048 0x7280 0 0.000040 0.095160 0.02000033

9452 76.0 126.0 102.3511 0x6A38 0 0.000032 0.070331 0.019997

20 150.0 150.0 150.00000x7C7B(Sender)

0x6F50(First source)0 4.990815 5.008854 5.00021237

40 150.0 150.0 150.00000x11A6(Sender)

0x604(First source)0 2.433994 5.018551 4.67089231

20 150.0 150.0 150.00000x7632(Sender)


64 150.0 150.0 150.00000x7280(Sender)


40 150.0 150.0 150.00000x11A6(Sender)

0x40EB(First source)0

9078 27940

7078 19518 RTPType-124

195197079

27941

SSRC Identifiers

(5)

Lost

Packets

(6)

RTPType-103

SR(200)

6.110196 4.806749512.458975

Host 2 Outgoing

RTP Packet Size(3)


Type(4)

Destination

Port(1)

Number of

Packets(2)

Source

Port(1)


Packets(s)(7)

9079


2000 57.0 1294.0 1044.02150 0x6F50 7 0.000021 0.274938 0.050460

3659 57.0 1294.0 1052.96938 0x604 12 0.000021 0.585956 0.05153664

5044 75.0 128.0 90.14000 0x1478 12 0.000019 0.227115 0.02004235

15396 74.0 130.0 79.63449 0x1288 28 0.000020 0.297903 0.02003480

9445 74.0 137.0 85.93721 0x40EB 4 0.000019 0.560520 0.020008

20 146.0 146.0 146.00000x6F50(Sender)

0x7C7B(First source)0 4.896326 5.115281 4.99939095

40 146.0 146.0 146.00000x604(Sender)

0x11A6(First source)0 2.494215 5.018851 4.73670282

20 146.0 146.0 146.00000x1478(Sender)


64 146.0 146.0 146.00000x1288(Sender)


40 146.0 146.0 146.00000x40EB(Sender)

0x11A6(First source)0

27940 9078

2.4796 8.63646 4.8873041

9079 27941

SR(200)

7079 19519

19518 7078

RTPType-103

RTPType-124

Destination

Port(1)

RTP Packet Size(3)


Packets(2)

Source

Port(1)


Packets(s)(7)Payload


Lost

Packets

(6)

Host 2 Incoming

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 PC’s. 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 2’s RTCP packet End of Host 1’s 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 1’s incoming stream and Host 2’s 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/ws-

project-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

http://www.ece.rutgers.edu/~marsic/books/CN/projects/wireshark/ws-project-3.html

http://www.ece.rutgers.edu/~marsic/books/CN/projects/wireshark/ws-project-3.html

http://www.ietf.org/rfc/rfc3550.txt

http://www.networksorcery.com/enp/protocol/rtp.htm

http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

analysis of rtp and rtcp packets in wireshark

Documents