A WIRESHARK VIEW OF REAL-TIME

CONTROL PROTOCOL (RTCP)
December 16, 2014 · by Andrew Prokop · in SIP · 14 Comments
I’ve been on a Wireshark binge these past few weeks. In November, I took you on a tour of a SIP
conference in Dissecting a SIP Conference Call and in December you got to see the nitty-gritty of transfer
in Dissecting SIP Transfer and media transmission in A Wireshark View of Real-Time Protocol (RTP).
Clearly, I am not the only geek around these parts because all three articles received quite a few views and
continue to trend fairly high.

I am going to press my luck a little further and write about RTP’s sister protocol, Real-Time Control
Protocol (RTCP). As you already know, RTP is used to transmit media between peers. As data are being
sent, RTCP packets are periodically generated by both the sender and the receiver. However, unlike RTP,
they don’t contain media. Instead, RTCP packets are used to report statistics about the ongoing call.

Although I don’t know if this is required, I have always seen RTP sent on an even numbered port and
RTCP on the adjacent odd numbered port. For example, if RTP is sent on port 5000, RTCP will be sent on
port 5001.

This article is meant to be a high level explanation of RTCP. For those of you who require a deeper dive, I
suggest you take a look at RFC 3550. It may put you to sleep, but it’s the ultimate authority on both RTP
and RTCP.

If you were to do a Wireshark trace of a basic SIP telephone call, you will notice a few things. First, there
are very few SIP messages involved in setting up a call. In fact, you can usually get by with only five
messages.

Second, there are a ton of RTP messages generated by the sender and the receiver. These packets will be
small and are sent using UDP.

Third, while you may see thousands of RTP messages for a fairly short call, you will only see a handful of
RTCP packets. The ratio for RTCP to RTP is not static, but dependent on a number of factors including
bandwidth and the number of participants in a conversation. I will refer you to the RFC for a detailed
explanation of how the ratio is calculated, but it’s enough to know that they are sent infrequently
compared to RTP.

There are five different reports used by RTCP:

  Sender Report (SR)

 Receiver Report (RR)

 Source Description (SDES)

 End of Participation (BYE)

 Application Specific (APP)

When I first read about the different reports, I expected to see them appear in separate packets. I quickly
learned that a single RTCP packet can contain more than one report. In fact, you typically see a minimum
of two in the same packet – SR and SDES.

I’ve never encountered RR or APP reports, but I am not surprised. RR reports are sent by passive
participants (participants that do not send RTP packets) and APP reports are used by applications to
extend RTCP with custom data. None of the clients I typically work with act in these manners.

The following is a packet commonly seen in a point-to-point audio call:

Note that this message contains both a Sender Report and a Source Description. If I open up the SR, we
see the following:

The SR will tell you the sender’s packet and octet count. In this example, we see that 3673 RTP packets
have been sent.

We also see a value for inter-arrival jitter. This can be used to determine the quality of service of this call.
In this example, the jitter is 42. RTCP expresses jitter in timestamp units.
If I open up the Source Description, we see this:

Here, I look at CNAME to learn a few things about the sender. Granted, I don’t see much here, but it may
be useful for the recipient.

The next commonly seen RTCP packet is the BYE report. Here is an example:

Note that this packet contains three reports – SR, SDES, and BYE. If I open up the Bye report we see the
following:

A BYE packet is sent when a participant leaves an RTP session. In the case of a point-to-point call, both
the caller and the called parties will send BYE reports.

Mischief Managed
Well, there you have it. I purposely glossed over the complexities of RTCP, but for the most part, you don’t
need to know them. Knowing that they are generated and can be used to create QoS reports should be
good enough for most people. Heck, it’s good enough for me and I do this for a living