Project 3:  Analysis of RTP and RTCP Packets

The goal of this project is to capture and analyze RTP and RTCP packets during a real-time conference session over a wired and wireless network.

Where to find information about RTP/RTCP:

This YouTube video explains how to decode RTP packets. It is not in English, but you can see how the author decodes the packets.

1.  Experiment Description

Install the Google Hangouts software on two or more computers in your project team.   Alternatively, you could use Apple Facetime.

Establish a conferencing session over a wireless/Wi-Fi LAN (activate both the audio and video options).
Each participant should be in a different geographic location, or at least should try to connect to a different wireless LAN while conferencing. Conference for about 5 – 10 min; longer durations will ensure more meaningful statistics, which is particularly important because these data will be used in WS Project 4.
At the same time all participants should use Wireshark to capture all the IP packets sent from their host and received from other host(s).
For example, knowing that the IP address of your host is, you could use these Wireshark filters:

ip.src ==
to display all packets sent from your host
ip.dst ==
to display all packets received by your host
Use traceroute  (Assignment #2) during or immediately after each session to determine the network paths between the participants. Each participant should determine their IP address and the destination IP addresses for all packets sent from their hosts (using Wireshark). Check if the destination address of the packets sent from your computer is the same IP address as that of another participant, or is it something else? You could use to determine the geographic location and the owner of the endpoint IP address.

Because of the complexity of this project, you may wish to first run some preliminary experiments to establish the methods for performing the actual experiments:

Describe these experiments in your report before you describe your actual experiments. Call this section “Methods” and describe the actual experiment in the “Experiments” section. It makes sense to describe the methods first, not the last.

Perform your experiment at least two times, once during a low-intensity network traffic, and once during a busy period, when you expect that many people will be using the same wireless network. (In your report describe the locations of all participants, which Wi-Fi networks they used, and during which times of day.)

2.  RTP and RTCP Packet Analysis

After capturing the packets, use Wireshark filters to partition the traffic to/from your computer so they can be analyzed separately.
The data preprocessing consists of the following steps:

  1. Separate the RTP data packets from RTCP control packets.
  2. Identify the encoding schemes used to create the packet payload for audio/video RTP streams.
  3. Determine the synchronization source (SSRC) identifiers for RTP packets.
  4. Determine different types of SSRC identifiers in RTCP packets (“reporter,” “first source,” …, “n-th source”)
The following subsections describe the details of each step.

2.1  Separating RTP and RTCP packets

The first step is to separate the RTP data packets from RTCP control packets. According to the Google Hangouts connection methods: “The UDP traffic consists of STUN, RTP, and RTCP packets, with SRTP encrypted data payloads.
Note that the conference participants will not be directly connected to each other, but indirectly via the Google conference servers (as you may have already discovered using traceroute).

It is not possible to recognize RTCP packets only based on their header. You must infer RTCP based on the UDP port—the UDP port(s) with majority packets are RTP data sessions. To separate the RTP data packets from RTCP control packets, use the fact that they are usually transmitted on different ports.
RFC-3550 on [Page 67] in Section 11:  “RTP over Network and Transport Protocols”  describes some guidelines on demultiplexing of RTP data and RTCP control streams. It says that:

   For UDP and similar protocols,
   RTP SHOULD use an even destination port number and the corresponding
   RTCP stream SHOULD use the next higher (odd) destination port number.
   For applications in which the RTP and RTCP destination port numbers are
   specified via explicit, separate parameters (using a signaling
   protocol or other means), the application MAY disregard the
   restrictions that the port numbers be even/odd and consecutive
   although the use of an even/odd port pair is still encouraged.
However, a particular application may implement something different from the recommended port assignment.
Even if RTP and RTCP connections are not over consecutive UDP ports, it should be easy to recognize the RTP data port by the significantly larger number of packets compared to RTCP control packets.

First list the number of packets that one participant’s computer received on different UDP ports (by using the Wireshark display filter udp.srcport).
For example, you may observe the distribution of packets on different UDP ports as shown in Table I.
Table I:  Incoming packets to Participant 1
Source Port Number Number of Packets Packet Type SSRC
103 (audio data)
99 (video data)
1638547 200 (RTCP SR) 1562797448 (reporter)
3459438840 (first source)
489794638 (second source)
26 201 (RTCP RR) 1172311862 (reporter)
3459438840 (first source)
489794638 (second source)
7 202 (RTCP SDES)
For clarity, indicate in your tables the type of RTP packet payload (audio or video). Later in the report explain how you determined this type (for dynamic types).

The remaining columns of Table I are described in the following subsections.
Also show the distribution of packets from the first participant to the second participant (Table II).
Table II:  Outgoing packets from Participant 1
Destination Port Number Number of Packets Packet Type SSRC
103 (audio data)
99 (video data)
1930331 200 (RTCP SR) 3459438840 (reporter)
1562797448 (first source)
1172311862 (second source)

You should show at least four tables in your report. For example, if your conferencing session had two participants, show separate tables for incoming and outgoing packets for each participant.
For each table, indicate the host on which the packets were captured and the direction (Inbound versus Outbound).

Note that the number and properties of RTP packets sent by one participant may not exactly correspond to those of packets received by the other participant. First, some packets may be lost in transmission (recall that UDP is an unreliable protocol). Second, the Google server over which the session is run may transcode audio or video from one compression format to another. As a result, more (smaller) packets or fewer (larger) packets may be received by the receiver than what the sender sent. Also, some of the packets’ parameters (such as SSRC identifiers) may be changed.

Note also that in addition to RTP data packets (audio or video), you may capture “RTP event packets” (shown in Wireshark as “RTP EVE”). These events support telephony-related signaling during the session, such as initiation of ringing tones. Check RFC-4733 for RTP payload format for named telephone events. List them in your tables, but do not mix them up with RTP data packets.

2.2  Identifying Payload Types for Audio/Video

The second step is to determine the encoding schemes used to create the packet’s payload for audio/video RTP streams. For example, G.711 is an audio codec.
RTP streams can only carry media from a single source. According to RFC-3550 on [Page 9], if both audio and video media are used in a conference, they should be transmitted as separate RTP sessions. That is, separate RTP and RTCP packets should be transmitted for each medium using a different UDP-port pair for each.
Again, a particular application may instead implement multiple media streams over the same UDP-port pair.

Using Wireshark packet inspection, determine the codecs used in RTP stream and write them down in your report. The RTP header has a 7-bit field named “payload type”, which indicates the specific encoding scheme used to create the packet’s payload. For example, in Google Talk types 99 and 126 represent video, and types 103 and 105 represent audio. See more details in Google Talk Call Signaling.
Google Hangouts uses dynamic load type range from 96 to 127 and does not specify which packet type is used for audio or video. One approach is to guess the RTP packet type (audio/video) based on the packet length.
A more accurate approach for finding of the packet payload type may be by turning the video option ON or OFF and seeing which RTP packets are missing or reappear. Similarly, you can “mute” audio and check which RTP packets are missing.
Perhaps the best way is to apply both approaches and see whether large-sized packets disappear when you turn off the video.

2.3  Synchronization Source (SSRC) Identifiers of RTP Packets

The third step is to determine the synchronization source (SSRC) identifiers for RTP packets. A synchronization source (SSRC) is source of a stream of RTP data packets, such as a microphone or a camera. Each source must be identified as a different SSRC. All packets from a synchronization source belong to the same timing and sequence number space, so a receiver groups packets by their synchronization source for playback.
A synchronization source may change its data format, e.g., audio encoding, over time. (See more details on [Page 9] of RFC-3550.)

Note that when showing the SSRC identifiers in your report (such as in Table I and Table II), the SSRC identifiers must be aligned with the packet types, so that it is clear which source generated which type of packets.

2.4  Determining SSRC Identifiers in RTCP Packets

All receivers of RTP data packets issue reports about reception quality by sending RTCP report packets to senders of RTP data packets.
If a receiver is also a source of RP data packets, then it generates sender reports (SR).
According to RFC-3550 (Section 6.4 on [Page 34]), the only difference between a sender report (SR) and a receiver report (RR), other than the packet type code (“200” versus “201”), is that the sender report includes a 20-byte sender information section for use by active senders. The rest of a sender report is exactly the same as a receiver report.
Note that if a source is only generating RTP data packets and sending them to receivers, but does not receive any RTP data packets from other sources, then sender report packets from this source do not contain receiver report blocks.

For explanation of the meaning of different types of SSRC identifiers in RTCP packets (“reporter,” “first source,” “second source,” …, “n-th source”), check the textbook (Section 3.4) and RFC-3550 (Section 6).
Here is a brief explanation:

Unfortunately, Wireshark currently does not support generating summaries of RTCP packets, unlike for RTP packets. Therefore, to extract this information, you will need to program your own code in a language such as C, C++, Java, or C#.

There are two main aspects of identifying SSRC identifiers in RTCP packets:

When displaying the statistics of RTCP packets in tables, ensure that entries in all rows are properly aligned so that the correspondences between port numbers, payload types, and SSRC’s are clear.
Also, it must be clear which “reporter” SSRC identifier appears with which “i-th source” SSRC identifier.

3.  Report Preparation and Submission

NOTE:  Keep the Wireshark data collected in this project because they will be used in WS Project 4.

As a minimum, include the following information in your report:

  1. Describe the experimental conditions:
  2. Describe your methods (such as the method for identifying payload type in RTP packets: audio versus video) near the front of the report. Include any experimental results that support your methods.
  3. IP addresses of the participating hosts. Draw the network paths between the participants for each traced route, as was done in WS Project 2.
  4. Statistics of captured packets for each experimental session and all participants (as in Table I and Table II). Use different tables for inbound and outbound packets and include the following: Ensure that entries in all rows are properly aligned so that the correspondences between port numbers, payload types, and SSRC’s are clear.
  5. All filters used for filtering the packets and description of what each filter does. Describe the exact procedure how you decoded UDP packets into RTP/RTCP and how you obtained the statistics shown in your tables.
  6. If you developed your own programs to extract statistics from the captured packets include your source code at the end of the report.
    The code must be properly described and commented to help the grader to understand it.
  7. List of references used during the data analysis and report preparation, such as websites, blogs, books, etc.
Discuss the differences in results for sessions recorded during periods of low-intensity network traffic versus the periods when the network is busy.

The items listed above form just a minimum requirement for the report and can be satisfied to a different degree. Only the students who have performed greatest number of experiments and provided most extensive analysis and discussion of their results shall receive the maximum score (100%).

The report format is the same as for project 1.

Submission deadline given on the course syllabus page.

@   Back to Wireshark projects page
&   Back to Computer Networks textbook page

Last Modified: Wed Oct  8 23:49:30 EDT 2014
Maintained by: Ivan Marsic