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.
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:
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
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:
|Source Port Number||Number of Packets||Packet Type||SSRC|
|103 (audio data)|
99 (video data)
|16385||47||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)||…|
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:
|Destination Port Number||Number of Packets||Packet Type||SSRC|
|103 (audio data)|
99 (video data)
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.
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.
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.)
As a minimum, include the following information in your report:
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