Project 3:  Analysis of RTP Packet Delays


The goal of this project is to capture and analyze delays of 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.

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 192.168.2.11, you could use these Wireshark filters:

ip.src == 192.168.2.11
to display all packets sent from your host
ip.dst == 192.168.2.11
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 Spy-IP.com to determine the geographic location and the owner of the endpoint IP address.

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.)

After capturing the packets, use Wireshark filters to partition the traffic to/from your computer so they can be analyzed separately.
The next step is to separate the RTP data packets from RTCP control packets and determine the encoding schemes used to create the packet’s payload for audio/video RTP streams. For example, G.711 is an audio codec.
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.

RTP streams can only carry media from a single source. See Synchronization source (SSRC) on [Page 9] of RFC-3550. 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.
Therefore, we use the following procedure.

Packets received by the first participant from the second participant:
First list the number of packets that your computer received on different UDP ports (by using the Wireshark display filter udp.srcport). Also 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.
For example, you may observe the following distribution of packets on different UDP ports:
Incoming packets to Participant 1
Source Port Number Number of Packets Packet Type SSRC
163846314
19304
103 (audio data)
99 (video data)
1562797448
1172311862
1638547 200 (RTCP SR) 1562797448 (reporter)
3459438840 (first source)
489794638 (second source)
26 201 (RTCP RR) 54793674 (reporter)
3459438840 (first source)
489794638 (second source)
7 202 (RTCP SDES)
163865
1640212
Note that when showing this table in your report, the SSRC numbers must be aligned with the packet types, so that it is clear which source generated which type of packets.
For explanation of the meaning of different types of SSRC numbers in RTCP packets (“reporter,” “first source,” and “second source”), check the textbook (Section 3.4) and RFC-3550 (Section 6).
Here is a brief explanation:

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.

Packets from the first participant to the second participant:
Outgoing packets from Participant 1
Destination Port Number Number of Packets Packet Type SSRC
193024394
11749
103 (audio data)
99 (video data)
3459438840
489794638
193036
193045
1930512

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.

2.  Captured Data Analysis

2.1  Calculating the Delay Jitter from RTP Packets

As this posting illustrates, extracting the delay jitter from RTP packets is not a straightforward task.

For each packet, calculate the delay as the difference between the packet’s timestamp (in the RTP header) and the time this packet arrived to your host. There may be some issues of aligning the time axes for audio and video, as discussed in  “How to calculate effective time offset in RTP”  and  “here.”  Calculate the averages of packet delays and standard deviations (known as "jitter"), for both audio and video packets.

Draw a histogram of packet delays. Ideally, you should show separate histograms for all experimental scenarios (depending on traffic intensity and data type rtp.p_type — video/audio). Your histogram should be shown so that delay values are along the horizontal axis and the frequency of measurement is along the vertical axis. The scale of the horizontal axis should be from the smallest delay value to the greatest delay value. Indicate the time units for the horizontal axis. The scale of the vertical axis should be from zero to the greatest frequency value. (Here “frequency” means how many times you observed a certain delay value.)

Traceroute from one participant to the other should give you some idea about which links seem to have the highest impact on packet delays.

2.2  Calculating the Fraction of Lost Packets

Analyze the timestamps and sequence numbers of the captured packets. By inspecting the gaps in sequence numbers, calculate the percentage of lost packets and write this in your report.
Note that the packet loss rate over the interval between RTCP Receiver Report (RR) packets can be derived from the cumulative statistics, as well as being directly reported. The difference in the cumulative number of packets lost gives the number lost during that interval, and the difference in the extended last sequence numbers gives the number of packets expected during the interval. The ratio of these values is the fraction of packets lost. This number should be equal to the fraction lost field in the RR packet if the calculation is done with consecutive RR packets, but the ratio also gives an estimate of the loss fraction if one or more RR packets have been lost, and it can show negative loss when there are duplicate packets. The advantage of the fraction lost field is that it provides loss information from a single RR packet. This is useful in very large sessions, in which the reporting interval is long enough that two RR packets may not have been received.

By analyzing trends in the reported statistics that are received by the sender (in RTCP Receiver Reports), determine whether any observed loss is a transient or a long-term effect.
Loss rates can be used to influence the choice of media format and error protection coding used. Check whether during your session you observed any such changes.

Draw a histogram of fractions of lost packets for each synchronization source (SSRC) reported in RTCP Receiver Report packets. (Draw a different histogram for each source.)

3.  Report Preparation and Submission

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

  1. Describe the experimental conditions:
  2. Name of the destination hosts and the date and time for each measurement. What type of media they correspond to (audio, video, etc., and the compression coding scheme)?
  3. List all the the types of RTP data packets observed in your experiments.
  4. For each experimental session, list the following:  The total number of captured packets of each type. The total number of packets sent by your host and the total number of packets received by your host. The total duration of each session.
  5. List all synchronization source (SSRC) identifiers observed in your experiments.
  6. The detailed procedure with exact formulas used for calculating the delay jitter.
  7. Histograms of fractions of lost packets for different SSRC’s. Also report the cumulative numbers of lost packets for each SSRC.
  8. All filters used for filtering the packets and description of what each filter does.
  9. Describe the exact filters you used and the exact procedure how you decoded UDP packets into RTP/RTCP and how you captured the local timestamp. Also, how did you do the calculations of the delay and delay jitter? If you used Matlab or some other language, include your source code.

Discuss the frequency distributions observed for different hosts and different observation periods.
Discuss the differences in results for sessions recorded during periods of low-intensity network traffic versus the periods when the network is busy.

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